7 ms·

Wow, var was so broken. 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

by krisdol 11y ago

Wow, var was so broken. 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.

zackify 11y ago
As of 5.4.0 arrow functions are more performant than binding, FYI: https://github.com/nodejs/node/pull/3622 https://github.com/nodejs/node/pull/3622
- krisdol 11y ago
  Woohoo! I've been hoping that this guy's Function.bind optimizations land before 6.0: http://benediktmeurer.de/2015/12/25/a-new-approach-to-function-prototype-bind/ http://benediktmeurer.de/2015/12/25/a-new-approach-to-functi... But you prompted me to check on the status of his work, and was happy to find a new post: http://benediktmeurer.de/2016/01/14/optimizing-bound-functions-further/ http://benediktmeurer.de/2016/01/14/optimizing-bound-functio... It looks like V8 will finally be able to inline bound functions (https://codereview.chromium.org/1581343002 https://codereview.chromium.org/1581343002)! That's huge!
Rezo 11y ago
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 11y ago
  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.
- mercer 11y ago
  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 11y ago
    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.)
alexkavon 11y ago
> 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.
- ergothus 11y ago
  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.
  - alexkavon 11y ago
    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.
    - alexkavon 11y ago
      Down-voters should be required to respond if they're going to down-vote. Too often is conversation halted by negative people on HN.

by krisdol 11y ago

zackify 11y ago

As of 5.4.0 arrow functions are more performant than binding, FYI: https://github.com/nodejs/node/pull/3622 https://github.com/nodejs/node/pull/3622

krisdol 11y ago
Woohoo! I've been hoping that this guy's Function.bind optimizations land before 6.0: http://benediktmeurer.de/2015/12/25/a-new-approach-to-function-prototype-bind/ http://benediktmeurer.de/2015/12/25/a-new-approach-to-functi... But you prompted me to check on the status of his work, and was happy to find a new post: http://benediktmeurer.de/2016/01/14/optimizing-bound-functions-further/ http://benediktmeurer.de/2016/01/14/optimizing-bound-functio... It looks like V8 will finally be able to inline bound functions (https://codereview.chromium.org/1581343002 https://codereview.chromium.org/1581343002)! That's huge!

Rezo 11y ago

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 11y ago
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.
mercer 11y ago
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 11y ago
  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.)

alexkavon 11y ago

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

ergothus 11y ago
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.
- alexkavon 11y ago
  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.
  - alexkavon 11y ago
    Down-voters should be required to respond if they're going to down-vote. Too often is conversation halted by negative people on HN.