8 ms·
Node.js ES2015/ES6 support
- amelius 11y agoI'd like to see a performance comparison with older versions. Some people here noted that these new ES2015/ES6 features are hurting the performance of old features. I have no idea whether this is true, so I think it would be best to just have the numbers.
- Ambroos 11y agoA bigger 'issue' for now is that most ES2015 features are (much) slower than their ES5 equivalents. Code transpiled with Babel will usually run quite a bit faster than running ES2015 directly, especially with Babel in loose mode.
- killercup 11y agoI too would love to see prove for that, and possibly a good benchmark suite so we changes in performance between releases.
- Ambroos 11y agohttps://kpdecker.github.io/six-speed/ https://kpdecker.github.io/six-speed/ is what I based my comment on. It seems to have improved since I last looked and ES6 will probably suffice performance-wise. Things like destructuring, are still 10x slower in Node 5.8 than through Babel, for example (and even 100x slower in Firefox). The spread parameter is similar. They're both used a lot in modern JS (when using Redux, for example). It's good that there are native implementations now, but both for performance and compatibility most people will/should probably keep transpiling ES6 for now.
- eyko 11y ago> Things like destructuring, are still 10x slower in Node 5.8 than through Babel, for example (and even 100x slower in Firefox). The spread parameter is similar. That's interesting. I had no idea there was such a drop in performance - orders of magnitude in some engines!
- madeofpalk 11y agoIt's not as much about ES6 constructs being slower, it's just that they're newer so haven't been optimised as much yet.
- ljoshua 11y agoThis is an important point. If your usage of these techniques is not on a hot critical path, I think there's much to gain by continuing to use them as the native optimizations continue to improve.
- bzbarsky 11y agoNote that this is comparing whatever Babel does with destructuring to the native implementation, in the same engine. This means two things: 1) Comparing these numbers across engines is pointless: if engine A runs the Babel code 5x faster than engine B but runs the native code at the same sped as enging B, this table will show engine A with a 5x bigger slowdown over Babel than engine B. 2) To make the comparison at all reasonable, this assumes the Babel implementation is correct per spec. I can't speak to what Babel is doing here, but simply looking at the tests in https://github.com/kpdecker/six-speed/tree/master/tests/destructuring https://github.com/kpdecker/six-speed/tree/master/tests/dest... it's clear that the "es5" version and "es6" version are testing different behaviors: the former indexes into the array, while the latter destructures it. Indexing is fundamentally a O(1) operation in array length, while destructuring is O(N) unless you manage to prove quite a lot statically about your operating environment, and they will produce different results in general (though again, if you can prove enough statically about your operating environment you may be able to prove that they are identical). This happens because in ES2015 array destructuring is defined in terms of array iteration, not indexing. In practice, proving anything statically about JS is a nightmare at best and impossible in pretty much any case of interest, so the best you can do with destructuring is dynamic sanity checks on the hot path... See also https://bugzilla.mozilla.org/show_bug.cgi?id=1177319 https://bugzilla.mozilla.org/show_bug.cgi?id=1177319 for some more info, though not much.
- stymaar 11y agoIt's been mentionned already on the thread talking about this benchmark: it's broken and does not give any interesting infos about real life performances (https://news.ycombinator.com/item?id=11203183 https://news.ycombinator.com/item?id=11203183)
- amelius 11y agoThis is important to fix, but I don't see this as a bigger issue. Imho, the most important is to keep the performance of existing code on par.
- Ambroos 11y agoRight, I worded it badly. The performance of ES6 code is more of an issue for people who want to switch from transpilers to running ES6 natively (something that's hard to recommend at this point). ES5 code performing slower because of ES6 features should indeed not happen and be avoided.
- untog 11y agoDoes anyone have a decent explanation of why? I'm confused why () => {} would be slower than function(){}.bind(this).
- tracker1 11y agoBecaue that binding is tigher than... (function(){ var __that = this; return function(){ /*switch __thatthat/this ref*/ }; }()); The code in question isn't just a binding, and it will have other differences... The code above is similar to what babel does iirc. Now, that said there are other differences, such as ensuring that let variables are properly scoped and const doesn't allow reassign... that doesn't even begin with the maps and other new strong types that require additional locking and checks that will be less performant in many scenarios. It's more about stable software with understandable, manageable code more than it is absolute, raw performance.
- bb85 11y agoFor your specific example, probably because the implementation is different. The most notable difference is that arrow functions do not set the "arguments" variable, but there are other subtleties. I'm not sure how it is done in V8 and co, but if the code is highly optimized, you might have to rewrite big chunks of it, even for small differences, because your optimizations do not go along with a slightly different implementation, or to avoid painful regressions.
- tilt 11y agoAre you referring to https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016 https://github.com/samccone/The-cost-of-transpiling-es2015-i... ? These benchmarks are about the cost of transpilation (where ES6 support is not native).
- amelius 11y agoNo I'm talking about V8 getting slower in general as a result of adding ES6 features.
- yoshuaw 11y agoThe Google v8 team discontinued work on strong mode because ES6 is 2x - 10x slower across the board. https://twitter.com/ahdinosaur/status/714999109741096960 https://twitter.com/ahdinosaur/status/714999109741096960
- gjolund 11y agoI can confirm this in my own projects as well.
- s3th 11y agoThis is a case of "make it work right; then make it work fast". ES2015 performance will improve with time (we've already made 8-10x improvements on certain features) [0]. Strong mode work was stopped for a variety of nuanced reasons detailed here [1]. (Disclaimer: I'm a PM on the V8 team.) [0]: https://twitter.com/addyosmani/status/699976753255751681 https://twitter.com/addyosmani/status/699976753255751681 [1]: https://groups.google.com/forum/#!topic/strengthen-js/ojj3TDxbHpQ https://groups.google.com/forum/#!topic/strengthen-js/ojj3TD...
- s3th 11y agoYou can see comparisons between ES5 and ES2015 feature equivalents, as well as comparisons with older versions at https://kpdecker.github.io/six-speed/ https://kpdecker.github.io/six-speed/. It's important to remember that implementation of ES2015 is merely the first pass; optimization comes soon after and will rapidly improve performance. General, absolute numbers (e.g. "ES2015 is X% slower than ES5") are usually either nonspecific or soon out-of-date. The best advice is to revise your performance assumptions frequently based on real code. r.e. ES5 side-effects: ES2015 adds language features and changes semantics of existing features in ways that necessarily change the execution path of code (including ES5 code). When V8 first tried implemented proper (ES2015) RegExp subclassing, for example, it regressed existing (ES5) RegExp performance by ~70%, but a subsequent optimization reduced the regression to ~9%. This is an unfortunate consequence of a rapidly evolving spec, but these cases are exceptional and will get better over time. (Disclaimer: I'm a PM on the V8 team.)
- neals 11y agoSo I'm an above average JS developer. I feel save saying this and claiming this. I would never use most of the exotic new stuff and I would probably never use any of the red stuff. I'm not saying it shouldn't be in there. I love that JS can be a fit for everybody. I just wonder how much we're gonna be adding and when it's enough...
- nkohari 11y agoLanguages constantly evolve. Java was created 20 years ago and it's still receiving regular updates.
- shriek 11y agoWhile I agree with you I also don't believe in adding things just for the sake of adding features. Remember, once you put a feature in a language it's going to remain in it forever and slowly the language can get bloated with lot of history in it's baggage (not that js already doesn't have this).
- mkohlmyr 11y agoObviously this is true, but I kind of agree with him. So far I don't use the overwhelming majority of new features and it does sort of seem like JavaScript is in some kind of race with itself to implement every paradigm and idea that anyone latches on to. There is beauty in simplicity and commonality in code. I don't think there would be anything wrong with taking a more conservative approach to adding new language constructs. JavaScript needed a class syntax. It needed block-scoped variables. It needed better parameter syntax and object loops. Generators are great. I'm not sure how much else of what is being added is strictly necessary as opposed to a technological debt for the future that must be supported for compatibility.
- likeclockwork 11y ago> JavaScript needed a class syntax. Did it? Or is that just a paradigm you've latched on to?
- Illniyar 11y agoThis doesn't seem like a complete list, what about modules? (I.E. import/export) which is (at least for me) the most interesting thing in es6 that needs to be implemented in node.
- k__ 11y agoAs far as I know only the module "syntax" is part of ES2015 (ES6). The rest isn't finished right now.
- stymaar 11y agoThe syntax and semantic are both finalized. Wath's remain open is the browser's module loader specification (https://whatwg.github.io/loader/ https://whatwg.github.io/loader/).
- eyko 11y agoModules were removed from the kangax test suite for reasons explained here: https://github.com/kangax/compat-table/issues/316 https://github.com/kangax/compat-table/issues/316
- Illniyar 11y agoI'm not sure I understand the reasons, is it mainly because the loader spec isn't finished yet?
- Touche 11y agoWhy do you think it's important that they implement import/export? Node already has a module system that works well. Support import/export is much more important in Browsers which has no module system.
- ihsw 11y agoBecause this one is superior. Why do we have cars if we can all walk just fine?
- islon 11y agoI wish they were adding power to js as they did to Lua: with simplicity. Instead they are doing doing the C++/Scala way: with complexity. Good thing I have Clojurescript...
- k__ 11y agoThey want to be backwards compatible, so what should they do? They can only discourage people to use the old stuff, if a better alternative is now available.
- jychang 11y agoRelease a Node.js version 10 with all the backwards stuff removed. Support the current version for LTS duration. Throw in a tool that does a lot of old->new conversion automatically, like the Python 2to3 tool. Come on, this is Node.js, not Win98.
- Klathmon 11y agoHas a massive big change like that ever worked smoothly in a language with really widespread use? I mean it's 8 years later and python is still feeling the issues from the 2->3 change.
- tonyedgecombe 11y agoOnly because they didn't deprecate 2 soon enough, they could have forced peoples hand, we would all have complained but it would be long forgotten by now.
- Klathmon 11y agoI don't believe that. I understand that some of the issue is lazy developers, but I really think that the majority of the problems would be caused by unmaintained code. Websites frequently sit around un-touched for years, hell our company website has some js code that was written by me over 4 years ago and hasn't been touched since because there's just no need to screw with it. And i'll be honest, it's not going to get updated until something breaks, and I would consider myself someone who likes to be on the cutting edge and is willing to endure breaking changes in more things than i should. I really think that by advocating for a "good" subset of the language, we can get all of the benefits of removing old stuff with very little of the downsides. Something like "use strict"; in javascript now. It removed many terrible things from the language in a way that you could mix old and new code together and get the benefits of both. That worked great, and i really think it could work great again. Something like a "use es6" or something that removes a massive set of "bad ideas" in the language, but it does it in a per-file or per-function basis. Allowing new code to be written in a better way, and allows old code to keep going as it was for a very long time.
- jarcane 11y agoI can't help but notice that once again tail call optimization seems to be one of the last things added, and even then requires a specific flag to work. Is there some reason for this pattern, like actual performance/technical difficulties, or is it more "My Java/C professor said recursion is bad"?
- epmatsw 11y agoFrom my understanding, there's not a lot of performance benefit in most cases and a performance degradation in others. Also there's some reluctance to change the behavior of existing code. Plus a whole bunch of unaddressed debugging issues (what does console.stack show?). https://github.com/tc39/proposal-ptc-syntax https://github.com/tc39/proposal-ptc-syntax
- cpeterso 11y agoAlso, how would script feature detect whether the VM implemented TCO? Code written assuming TCO would still run, but very inefficiently.
- dsp1234 11y agoFor Node.js, define a simple function that does minimal computation, but that would blow the stack if called say a million times[0]. Run that function inside of a new vm context[1]. If it errors with a stack overflow, then no TCO. [0] - function n(x){if(x > 0) n(x-1)} [1] - https://nodejs.org/api/vm.html#vm_vm_runinnewcontext_code_sandbox_options https://nodejs.org/api/vm.html#vm_vm_runinnewcontext_code_sa...
- mirekrusin 11y agoWow, Proxy is there, awesome. I find it strange nobody mentions Proxy, it's so cool to finally have it...
- coroutines 11y agoWe are now friends. Hello friend. :D
- iamleppert 11y agoIt seems crazy to me that performance takes a backseat to syntactical sugar, which is most of what ES6 provides. There are a few new constructs, but in my mind when is it ever acceptable to have performance regressions to make the code look pretty? And the fact that it isn't optional is alarming. If you use the new features, you should have to suffer performance penalty if there is one, and at least be able to make that design choice and trade-off between "cleaner" or "prettier" code and poor performance. I don't think you can call something "complete" or green until the performance issue is solved.
- tracker1 11y agoIt's better to make something that works, and then improve performance as-needed than to try and optimize before hand. You don't always know the real world impact of a given solution until you have one, and synthetic tests aren't a reflection of real world impact. Beyond this, I happen to like a lot of the sugar. It makes code simpler, cleaner and in most cases easier to comprehend... Sometimes the fat arrow functions returning fat arrow functions gets a little weird, but outside of that, it's a pretty big benefit. Async functions will help a lot as well once they land, for now, Babel works well enough.
- _greim_ 11y agoIt isn't that this new syntax is slow, so much as V8 has a shit-ton of internal machinery dedicated to optimizing specific execution paths, and it is those things which get a massive efficiency boost. In that sense, becoming syntax complete is just a first step down a very long road.
- s3th 11y agoSee my comment below: https://news.ycombinator.com/item?id=11564354 https://news.ycombinator.com/item?id=11564354 It's not so simple as (paraphrasing) 'ES6 is sugar and makes ES5 regress in speed.' Generally, "make it work right, then make it work fast" is actually a pretty good strategy for implementing new features.
- tracker1 11y agoI think it's awesome how well the V8 team is working on these features, and how much more closely the Node core teams are working with the V8 teams. Much better coherence than in the past. (at least from the perspective of a mostly passive observer). There are a few bits wrt ES2016/2017 that I'm hoping come in before long as well... will be nice to no longer feel the need for babel, at least on the server-side pieces of many projects.
- rail2rail 11y agoWould be great if each section linked to a description of the functionality. This would help new users and those trying to level up skills. Sure you can just Google it, but it would make this chart that much more useful.
- paradite 11y agoDoes anyone know if Node.js will have backports for ES6 in version 4.X? Would love to use ES6 in my current project but I don't want to move from Node.js 4.X to 5.
- jyunderwood 11y agoI would assume the answer is no. Backporting ES6 features could introduce some breaking changes. You could transpile your code with something like Babel[1]. [1]https://babeljs.io/ https://babeljs.io/
- tracker1 11y agoI'm a fan of async functions, so will be using Babel on the front and back for a while to come.
- deleted 11y ago[deleted]
- kapv89 11y agoReally Impressed by how quickly node.js has moved after the merge with io.js and the formation of node foundation.