4 ms·

Isn't Babel 93% redundant on the server side now? If you're not very dependent on the last 7% I'd just remove it.

by benologist 11y ago

veeti 11y ago
I use it to transform async/await into generators for Koa. The module syntax is also much nicer to use.
- koolba 11y ago
  Maybe I've got Stockholm syndrome but I prefer the module.exports style.
- tracker1 11y ago
  Came to note the same... really like async functions.
matt4077 11y ago
There's one remaining problem: V8 ES6 support is quite new and less optimized. If you're looking for optimal performance, you'll be transpiling for a long time (or possibly forever, 'cause those ES7 features are tempting, aren't they?)
- grayrest 11y ago
  Can't wait on that Exponentiation Operator and A.p.includes!
  - SerpentJoe 11y ago
    As you indicated, almost none of what was once called ES7 made it into the final spec: http://www.2ality.com/2016/01/ecmascript-2016.html http://www.2ality.com/2016/01/ecmascript-2016.html At least exponentiation is slightly cool. Hasta la ES8 siempre I guess.
nostrademons 11y ago
The big missing thing is modules, which aren't in the kangax compatibility table.
- tracker1 11y ago
  In fairness, the babel approach to module handling is probably better than an in-browser es6 module implementation, or what may follow... compatibility with npm packages (cjs) will be significant for a while.
  - nostrademons 11y ago
    My understanding is that V8 will provide hooks that parse the module imports, then delegate to the embedder to fetch the actual source code and hand it back to V8 to load. I'd expect that the Node implementation of these hooks would work the same way as the existing require() machinery, so that existing libraries will continue to work.
- bmeck 11y ago
  ES2015 did not include a loader specification, only a module specification. https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md https://github.com/nodejs/node-eps/blob/master/002-es6-modul... is the interop that will be present for node but it is outside of JS spec itself.
savanaly 11y ago
The javscript version of the hedonic treadmill ensures there will always be a juicy new feature that node/browsers don't have yet but Babel/other transpilers usually will. Just because it's 93% of the way there on ES6 at this moment doesn't mean that a few months from now people, your team included, won't be clamoring to be able to write with the new sweet features from ECMAScript 2017 or whatever. The only solution is to keep Babel a part of your stack perpetually and really that's not so bad in my opinion.
- nemild 11y ago
  Remember that performance with Babel transpiled code is still sometimes faster (in some cases, substantially so) than the native ES6 implementations, as optimizing continues on V8's end. And be sensible about how much transpilation you want, you can use newer presets that don't need to transform the code as much, while still having the ability to layer in newer features (async/await, ES7, etc).

Isn't Babel 93% redundant on the server side now? If you're not very dependent on the last 7% I'd just remove it.

veeti 11y ago

I use it to transform async/await into generators for Koa. The module syntax is also much nicer to use.

koolba 11y ago
Maybe I've got Stockholm syndrome but I prefer the module.exports style.
tracker1 11y ago
Came to note the same... really like async functions.

matt4077 11y ago

There's one remaining problem: V8 ES6 support is quite new and less optimized. If you're looking for optimal performance, you'll be transpiling for a long time (or possibly forever, 'cause those ES7 features are tempting, aren't they?)

grayrest 11y ago
Can't wait on that Exponentiation Operator and A.p.includes!
- SerpentJoe 11y ago
  As you indicated, almost none of what was once called ES7 made it into the final spec: http://www.2ality.com/2016/01/ecmascript-2016.html http://www.2ality.com/2016/01/ecmascript-2016.html At least exponentiation is slightly cool. Hasta la ES8 siempre I guess.

nostrademons 11y ago

The big missing thing is modules, which aren't in the kangax compatibility table.

tracker1 11y ago
In fairness, the babel approach to module handling is probably better than an in-browser es6 module implementation, or what may follow... compatibility with npm packages (cjs) will be significant for a while.
- nostrademons 11y ago
  My understanding is that V8 will provide hooks that parse the module imports, then delegate to the embedder to fetch the actual source code and hand it back to V8 to load. I'd expect that the Node implementation of these hooks would work the same way as the existing require() machinery, so that existing libraries will continue to work.
bmeck 11y ago
ES2015 did not include a loader specification, only a module specification. https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md https://github.com/nodejs/node-eps/blob/master/002-es6-modul... is the interop that will be present for node but it is outside of JS spec itself.

savanaly 11y ago

The javscript version of the hedonic treadmill ensures there will always be a juicy new feature that node/browsers don't have yet but Babel/other transpilers usually will. Just because it's 93% of the way there on ES6 at this moment doesn't mean that a few months from now people, your team included, won't be clamoring to be able to write with the new sweet features from ECMAScript 2017 or whatever. The only solution is to keep Babel a part of your stack perpetually and really that's not so bad in my opinion.

nemild 11y ago
Remember that performance with Babel transpiled code is still sometimes faster (in some cases, substantially so) than the native ES6 implementations, as optimizing continues on V8's end. And be sensible about how much transpilation you want, you can use newer presets that don't need to transform the code as much, while still having the ability to layer in newer features (async/await, ES7, etc).