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.)
(function(){
var __that = this;
return function(){
/*switch __thatthat/this ref*/
};
}());
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.
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.
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.
That's interesting. I had no idea there was such a drop in performance - orders of magnitude in some engines!
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/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 for some more info, though not much.
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 [1]: https://groups.google.com/forum/#!topic/strengthen-js/ojj3TD...
These benchmarks are about the cost of transpilation (where ES6 support is not native).