3 ms·
The author posits that "Babel should come pre configured with the kitchen sink of JavaScript development - async await, decorators etc etc." There's a very goo
by taion 11y ago
The author posits that "Babel should come pre configured with the kitchen sink of JavaScript development - async await, decorators etc etc."
There's a very good reason that Babel doesn't, and we should actually be fairly grateful that the Babel team have made the considered decision not to include such things.
First off, neither async/await nor decorators are actually part of ES2015. They're both TC39 proposals, at various stages of completion: https://github.com/tc39/ecma262 https://github.com/tc39/ecma262. Very justifiably, neither Babel 5 nor Babel 6 transpiled those out-of-the-box by default; for novice programmers, using language features that are unstable proposals that have not finalized is quite dangerous – what are you going to do if those proposals change, as the decorators proposal actually has changed?
More specifically, there are meaningful issues with both of those transforms if used without further thought. Babel's stock transpilation of async/await brings in an entire runtime component in the form of the Regenerator runtime, and additionally requires that Promises exist in the JavaScript environment, which requires polyfills in the general case.
For decorators, the proposal itself is still in flux. The current version of the proposal (https://github.com/wycats/javascript-decorators/blob/master/interop/reusability.md https://github.com/wycats/javascript-decorators/blob/master/...) is actually quite different from the old proposal, which was the one that was implemented in Babel 5. Additionally, the current proposal isn't even fully nailed down yet. Certainly one should not expect Babel to implement a language feature for which there isn't even yet a stable proposal!
This isn't to say that Babel 6 is perfect, but the specific counterexamples the author of this post brings up are extremely weak, and if anything demonstrate very good choices on the part of the maintainers of Babel.
- andrewstuart 11y ago>>what are you going to do if those proposals change, as the decorators proposal actually has changed? I'd just update my code to meet the spec. Likely it would take vastly less time than the hours needed to fail in configuring Babel. The documentation can just say "this feature isn't finalised, it might change." That's enough. The code does not need to be disabled just because the spec isn't final. >> quite dangerous It's not really dangerous. No-one is going to die. It's emotive words like dangerous that lead Babel developers to think "we'd better hide that functionality behind hard-to-configure barriers so people don't cut themselves on the dangerous code".
- thejameskyle 11y agoIt's extremely dangerous, we're talking about tens of thousands of developers who have chosen to depend on Babel for their livelihood, we can't just keep breaking things on them. We don't want Babel's configuration to be difficult, we just want people to explicitly tell us what they want. If you have suggestions on how to make the configuration easier I'm happy to hear it. But turning stuff on by default it a terrible terrible decision that hurts the community.