[Rezo]

Transpiling on the fly on the server is even more painless than for the frontend:

- Require babel-core/register (as of Babel 6) - Require your server entry point ES6 file. - Done.

Everything just seems to work, no need for sourcemaps or anything; line numbers, error reporting, non-ES6 modules, everything Just Works. Haven't had a single issue since starting to do this 4 months ago (knock on wood). Highly recommended!

[krisdol]

It's not that I don't know how to set it up or use it, I just trust a future V8 implementation enough to wait for it over using a shim. I've also become a bit allergic to dependencies :P.

I do trust that it works, and if I were working on a big project that would be hard to refactor for a major language change, or if I were working on the front-end where the available features are up to question based on client, I would definitely use babel. We have a lot of older code like that where I wish we had used babel years back.

In my case our backend is distributed across dozens of small (usually <400 line) packages so if a really nice ES2015 or 2016 feature becomes available the effort to refactor or rewrite will be measured in hours or days, not weeks or months.

[mstade]

Additionally, if you're using tape[1] for testing, I implemented a useful feature not too long ago to allow the preloading of modules[2] so you can run something like babel-register before your tests are run, effectively plugging in JIT-like support for your tests. (End shameless plug.)

[1]: https://github.com/substack/tape

[2]: https://github.com/substack/tape#preloading-modules

[mercer]

The babel documentation says it's a bad idea to do this in production, so I'm thinking of using webpack to transpile then entire back-end to one ES5 file. Do you know enough about this situation to tell me if this is a bad idea or not? Because obviously your approach would be 'simpler'.

Edit: An additional reason to transpile to ES5 is that on the whole much of the ES6 support is not very performant yet. While this might not matter for incidental uses of, say, template strings, it might become noticeable for an entire project. Or is that a clear case of premature optimization?

[mstade]

There's no difference in compiling to ES5 versus hooking into the module loading mechanism to compile on the fly, in terms of the end-result. The only practical difference is that precompiling means your modules will load faster the first time, but there will be no difference for subsequent loads since modules are cached. I'm guessing the caveat for running something like babel-register in production is the first-load performance penalty, as well as having less control over the compilation process. However, if you are ok with configuring babel through .babelrc files alone, and you're ok with the first-load performance penalty, I don't see what it'd be any worse than precompiling to ES5. (There may be subtle differences in debugging due to the lack of source maps, but I don't know enough to comment on that with any degree of certainty.)

[mercer]

That's informative, thanks. At least I have something to look into, and a quick search indicates that source maps are not even necessary in this approach!

[dham]

babel-register is not recommended for production use.

https://phabricator.babeljs.io/T6940

That being said I've used in production for quite a while, but the memory foot print is a lot higher. I'd recommend compiling to a separate file for production.

I recently put in the pull request to suggest not using register in production just as babel-node is not recommended.