5 ms·
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
by pfooti 11y ago
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 11y agoNot just performance overhead, but also the overhead of maintaining and configuring the extra bits of toolchain.
- balupton 11y agoWe'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 https://github.com/bevry/base#esnextguardian