Anyway, we use as much ES6 as Node 4 allows at work. Transpiling on the server never made much sense to me. I also used to sprinkle the fat-arrow syntax everywhere just because it looked nicer than anonymous functions, until I realized it prevented V8 from doing optimization, so I went back to function until that's sorted out (I don't like writing code that refers to `this` and never require binding, so while the syntax of => is concise, it is rarely used as a Function.bind replacement). Pretty much went through the same experience with template strings. Generator functions are great.
I'm not a fan of the class keyword either, but to each their own. I think it obscures understanding of modules and prototypes just so that ex-Class-based OOP programmers can feel comfortable in JS, and I fear the quagmire of excessive inheritance and class extension that will follow with their code.
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!
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.
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.)
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?
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.)
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!
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.
> I'm not a fan of the class keyword either, but to each their own. I think it obscures understanding of modules and prototypes just so that ex-Class-based OOP programmers can feel comfortable in JS
I couldn't agree more. Classes were implemented so that JS haters could write syntax they wanted to and not to improve the language per say. Seems like JS is entering an age of cruft.
While I am also not a fan of the class keyword, I'd argue that we already had that age of cruft. For quite a few years (past decade?) practically every book on JS would start with the author building their own version of inheritance, and then relying on it throughout the rest of the book.
It's only in the last few years that the majority have stopped trying to recreate Java in JS. (I don't think the majority of PRACTITIONERS were doing this, but the majority of INSTRUCTORS were, causing a lasting problem until enough people willing/able to teach were grown within the community.
Agreed. I think JS is quite a broken language that should probably be replaced. It won't be, but it probably should. I know Google thinks Dart could be that language but they're not even trying to put the VM into Chrome, so it's just another replacement that needs to be compiled.
I was complaining about some JS stuff (particularly the required writing of "use strict") in the #nodejs freenode irc chat the other day and someone asked me a way to help solve these issues without breaking 50 year old code. Thinking about it, I think a good attempt would be to create an HTML meta tag that would tell the browser to parse all JS in strict mode. Maybe there's something already out there. This is already possible in nodejs, but browser side I think it could be a big help in moving things forward.
Isn't that basically what we did with doctypes? HTML has a lot of similar issues and it has slowly managed to move forward. The real benefit was not having to mix old and new code and getting rid of all the quirks by requiring you specify that you want them if you want that old doc to work.
JavaScript could get to the same place just be letting you specify a different language in the script tag.
The big question is how we support legacy browsers for a time because many won't support the new keywords.
A script type could work too. Either way, there would be some indicator of how the JS VM could parse the code. It's true you could get other languages into HTML this way as well, but the trick is that the browser needs to support the VM, which can be done natively or through a browser plugin/extension. Google tried this for a Dart VM (sidenote: there is no TypeScript VM from Microsoft that I'm aware of) into Chrome but discussions led away from that idea, and now Dart compiles to JS instead. A <meta> tag in <head> would eliminate <script type="application/sjavascript"></script>, <script type="application/sjavascript"></script>, etc. Though providing an either/or situation would be optimal too to allow a mixed script types for older libraries.
> While I am also not a fan of the class keyword, I'd argue that we already had that age of cruft. For quite a few years (past decade?) practically every book on JS would start with the author building their own version of inheritance, and then relying on it throughout the rest of the book.
This, right here. The class keyword is unfortunate, but at least it ends the useless meta discussion of "how to implement classes" by simply providing some sugar over the RightWayToDoIt(tm). (According to those in the know – whatever, I don't care for classes.)
Anyway, we use as much ES6 as Node 4 allows at work. Transpiling on the server never made much sense to me. I also used to sprinkle the fat-arrow syntax everywhere just because it looked nicer than anonymous functions, until I realized it prevented V8 from doing optimization, so I went back to function until that's sorted out (I don't like writing code that refers to `this` and never require binding, so while the syntax of => is concise, it is rarely used as a Function.bind replacement). Pretty much went through the same experience with template strings. Generator functions are great.
I'm not a fan of the class keyword either, but to each their own. I think it obscures understanding of modules and prototypes just so that ex-Class-based OOP programmers can feel comfortable in JS, and I fear the quagmire of excessive inheritance and class extension that will follow with their code.