Hacker News new | past | comments | ask | show | jobs | submit login

Equally honest counter-question: all modern browsers essentially support ES2019 already, so why would anyone still need babel outside of turning JSx into JS because React is still a hot tech, or in order to turn normal modern code into the kind of legacy code that >99% of your visitors won't need?

I'm sure there are plenty of build systems out there that still indiscriminately turn things into ES5, because "that's how we wrote it years ago and it still works", but anyone who actually cares about performance will think twice before using babel today to turn nice, clean, concise modern code into incredibly verbose and shimmed legacy code, and will certainly think twice before serving ES5 code to users on a modern browser.




There's a handful of unsupported features I play with... the null operators and pipelines in particular. But I do set my presets for pretty modern support as a baseline. I still use webpack as well.


Webpack is just a bundler, it doesn't turn modern code into overly verbose legacy code on its own. Babel's the real troublemaker because by default it's still acting like it's the original 6to5 package. Using it to turn draft features into working ES2018 is sensible, using it to convert all the way down to ES5 for anything that isn't IE11 (which is basically the only legacy browser left at this point), not so much.


Agreed. That's why my baseline is at least async support. Every modern browser has supported it for about 2 years now, and regenerator+asynch was the single biggest part of legacy transforms. I did have a second config for legacy, but at my current job was able to drop support, and just show unsupported browsers a message page now.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: