4 ms·

BabelJS's idea is so simple, yet huge. BabelJS, or, as I like to call them in my talks, is the "Age of transpilers". The idea of having some sort of meta layer

BabelJS's idea is so simple, yet huge. BabelJS, or, as I like to call them in my talks, is the "Age of transpilers". The idea of having some sort of meta layer that you compile from to another source is old, but totally underrated: https://en.wikipedia.org/wiki/Source-to-source_compiler https://en.wikipedia.org/wiki/Source-to-source_compiler With my team we optimized render processes using transpilers/meta language and this totally rocks. I hope that BabelJS will continue to follow their vision and gets more sponsorship from company-side. For me, they popularized the idea of Compilers in unexpected areas.

baybal2 5y ago
Transpilers are bad. They add to the already giant mess of unnecessary JS tooling. How much of them is really needed, and how much is there just for webdevs to show their "street cred?" Not a lot at all. Not only the debugging is breaking down because of them, but they often introduce bugs on their own which are very hard to find. Framework authors force involuntary decision to use transpilers on people downstream, and everything suffers from that: "feature A breaks with transpiler B 1.2.3," but because end users simply don't use them, and thus don't file bugs, devs don't know that either.
- Cthulhu_ 5y ago
  Babel has allowed developers to write modern JS without having to worry about older browsers - which, granted and thankfully, is now much less of an issue thanks to evergreen browsers and Microsoft having stopped with IE. Typescript and Flow allow for much higher quality software without having to add complexity to browsers (like Dart initially was intended to).
- switz 5y ago
  Nonsense. Transpilers have been misused at times in the javascript community, but overall they have played a *massive* role in modernizing javascript and enabling us to write much sounder, more robust, and bug-free code that runs everywhere, including on older devices and runtimes. Society as a whole has benefited immensely from babel and other transpilers. As time goes on, transpilers may ultimately become slightly less valuable, however for the past decade they have allowed us to grow and improve our javascript without sacrificing portability.
  - baybal2 5y ago
    Baseline ES6 been supported for many years now. There are very few things a transpiler will do for you today. Some critical langauge features are completely impossible to substitite, or emulate. Given this, what's the point? The few non-critical features can be more reliably polyfilled manually than relying on transpiler which will mangle the rest of your code which has nothing to do with that function, and with 50/50 chance to introduce own problems.
    - ilkkao 5y ago
      I was able to remove babel few weeks ago in one of my projects when webpack started to support class properties natively. The project in question only supports evergreen browsers. So nice to have super simple build config. I have nothing against babel. I think it's great especially in maturing TC39 drafts.
- mort96 5y ago
  Being anti-transpiration seems really weird to me? It just lets developers write code using new standards without requiring all users to be on bleeding edge browsers. What do you think should happen instead? Should web applications just exclude anyone who's using a browser that doesn't implement all the newest web standards? Or should developers just unnecessarily use old versions of JavaScript? You might not be aware, but writing in ES5 feels incredibly awkward once you get used to the newer standards. If I can write in a nice language (ES2020) but transpire my code into a more widely supported language (ES5) I don't see why I wouldn't do that.
  - baybal2 5y ago
    First, wringing code which is debuggable, and experience less perturbations will alone add to better code longevity, and maintainability. I lost count to cases when old code is unsalvageable because the tooling combination used to "build" it simply refuses to work with modern nodejs, distro, or some other dependency. There were very few vital features introduced since ES6, and some of them were in browser earlier than major ES releases. Browser APIs did change, but those have no bearing on the JS/ECMA language support And the few remaining things are so hard to polyfil, and so hacky that I see myself no point in using them: 1. ES6 Proxy - possible to polyfill, but hacks involved are just terrible. Basically the only way to do it is to re-implement half of Javascript VM inside the your Javascript. 2. Async/await - possible to polyfil, but all polyfills are of extremely low performance, and high memory consumption. They send desktop PCs fans' spinning, and I don't want them. 3. Intl API - what's the point of using a system INTL functionality, if you yourself polyfill it? Just implement the string substitution in the code. And so on, and on
- majjgepolja 5y ago
  Compilers are bad. They add to the already giant mess of unnecessary assembler tooling. How much of them is really needed, and how much is there just for embedded developers to show their "street cred?" Not a lot at all. Not only the debugging is breaking down because of UB, but they often introduce bugs on their own which are very hard to find. Library authors force involuntary decision to use compilers on people downstream, and everything suffers from that: "feature A breaks with compiler G* 5.0," but because end users simply don't use them, and thus don't file bugs, devs don't know that either.

baybal2 5y ago

Transpilers are bad. They add to the already giant mess of unnecessary JS tooling. How much of them is really needed, and how much is there just for webdevs to show their "street cred?" Not a lot at all. Not only the debugging is breaking down because of them, but they often introduce bugs on their own which are very hard to find. Framework authors force involuntary decision to use transpilers on people downstream, and everything suffers from that: "feature A breaks with transpiler B 1.2.3," but because end users simply don't use them, and thus don't file bugs, devs don't know that either.

Cthulhu_ 5y ago
Babel has allowed developers to write modern JS without having to worry about older browsers - which, granted and thankfully, is now much less of an issue thanks to evergreen browsers and Microsoft having stopped with IE. Typescript and Flow allow for much higher quality software without having to add complexity to browsers (like Dart initially was intended to).
switz 5y ago
Nonsense. Transpilers have been misused at times in the javascript community, but overall they have played a *massive* role in modernizing javascript and enabling us to write much sounder, more robust, and bug-free code that runs everywhere, including on older devices and runtimes. Society as a whole has benefited immensely from babel and other transpilers. As time goes on, transpilers may ultimately become slightly less valuable, however for the past decade they have allowed us to grow and improve our javascript without sacrificing portability.
- baybal2 5y ago
  Baseline ES6 been supported for many years now. There are very few things a transpiler will do for you today. Some critical langauge features are completely impossible to substitite, or emulate. Given this, what's the point? The few non-critical features can be more reliably polyfilled manually than relying on transpiler which will mangle the rest of your code which has nothing to do with that function, and with 50/50 chance to introduce own problems.
  - ilkkao 5y ago
    I was able to remove babel few weeks ago in one of my projects when webpack started to support class properties natively. The project in question only supports evergreen browsers. So nice to have super simple build config. I have nothing against babel. I think it's great especially in maturing TC39 drafts.
mort96 5y ago
Being anti-transpiration seems really weird to me? It just lets developers write code using new standards without requiring all users to be on bleeding edge browsers. What do you think should happen instead? Should web applications just exclude anyone who's using a browser that doesn't implement all the newest web standards? Or should developers just unnecessarily use old versions of JavaScript? You might not be aware, but writing in ES5 feels incredibly awkward once you get used to the newer standards. If I can write in a nice language (ES2020) but transpire my code into a more widely supported language (ES5) I don't see why I wouldn't do that.
- baybal2 5y ago
  First, wringing code which is debuggable, and experience less perturbations will alone add to better code longevity, and maintainability. I lost count to cases when old code is unsalvageable because the tooling combination used to "build" it simply refuses to work with modern nodejs, distro, or some other dependency. There were very few vital features introduced since ES6, and some of them were in browser earlier than major ES releases. Browser APIs did change, but those have no bearing on the JS/ECMA language support And the few remaining things are so hard to polyfil, and so hacky that I see myself no point in using them: 1. ES6 Proxy - possible to polyfill, but hacks involved are just terrible. Basically the only way to do it is to re-implement half of Javascript VM inside the your Javascript. 2. Async/await - possible to polyfil, but all polyfills are of extremely low performance, and high memory consumption. They send desktop PCs fans' spinning, and I don't want them. 3. Intl API - what's the point of using a system INTL functionality, if you yourself polyfill it? Just implement the string substitution in the code. And so on, and on
majjgepolja 5y ago
Compilers are bad. They add to the already giant mess of unnecessary assembler tooling. How much of them is really needed, and how much is there just for embedded developers to show their "street cred?" Not a lot at all. Not only the debugging is breaking down because of UB, but they often introduce bugs on their own which are very hard to find. Library authors force involuntary decision to use compilers on people downstream, and everything suffers from that: "feature A breaks with compiler G* 5.0," but because end users simply don't use them, and thus don't file bugs, devs don't know that either.