Hacker News Reader

Comment by benologist | Hacker News Reader

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.

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?)

Can't wait on that Exponentiation Operator and A.p.includes!

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

At least exponentiation is slightly cool. Hasta la ES8 siempre I guess.

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.

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).

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

ES2015 did not include a loader specification, only a module specification. 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.

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.

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.

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

Came to note the same... really like async functions.

Maybe I've got Stockholm syndrome but I prefer the module.exports style.

Reply on news.ycombinator.com