[pfooti]

Yeah, this is rad, as I imagine there's some overhead to running the transpiled babel ES6 code compared to running the native ES6 features. At least some things may be faster - I remember lexical block scoping (let and fat arrow) causing perf issues in traceur.

Now I just need to be able to rely on these features being present in the browser so I can just write native ES6 everywhere and skip that build step entirely.

[azernik]

Not just performance overhead, but also the overhead of maintaining and configuring the extra bits of toolchain.

[balupton]

We've been using a concept of a "esnextguardian" to be what our package.json main points to, it then tries and loads the es6+ version and if that fails, fallbacks to the compiled es5 version. It's been working quite well for all our different Bevry projects. More info: https://github.com/bevry/base#esnextguardian