Hacker News Reader

Comment by daliwali | Hacker News Reader

Most ES6 features are either equal to or worse than their ES5 counterparts in terms of performance, some by orders of magnitude (!)

For example, `class` has particularly bad performance characteristics because under the hood it has to set an object's prototype on the fly (at least this is how Babel implements it) [1] and `super` is also slow due to prototype lookup [2].

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2] https://jsperf.com/es6-classes-super-es5-vs-transpiled/2

View on HN

FYI, when compiled with Babel 5's loose mode, the transpiled code is roughly similar to what you'd hand-write:

https://babeljs.io/repl/#?experimental=true&evaluate=true&lo...

I didn't test the performance impact though. Also it's still a mystery to me how to enable Loose mode in Babel 6.

You should read this http://www.2ality.com/2015/12/babel6-loose-mode.html

If you need to make 30 million function calls per second, the ES5 counterparts aren't off limits. I hear the performance argument against early ES6 adoption from time to time. But the bottleneck when running javascript on the client or the server is almost never language constructs. Network requests, disk i/o, database queries...they're all going to take many thousands of times longer than a prototype lookup. We should write succinct code first, then optimize the slow parts.

Recently I've rewritten ES6 code to ES5, and have measured performance gains in doing so, not orders of magnitude faster but overall just a bit faster at everything. I think that even CoffeeScript does a better job at being succinct, and it transpiles to pretty fast ES5 code.

I'm curious to know in what scenario one may benefits from this kind of rewriting.

I guess your application: - doesn't intensely manipulate the DOM (otherwise your js performance shouldn't really be the bottleneck). - isn't easy to parallelize. - or you already make massive usage of web workers and you still had issues.

No sarcasm at all, I've recently refactored in ES6 the code-base I'm working on, without noticing any performance issues, and we really gained in readability and maintainability doing so. That's why I really wonder what could lead me to do the exact opposite.

You should really qualify that with "transpiled ES6 features". Native implementations will not necessarily be slower.

I think this is incorrect, some features are by definition slower. Take for example the iterable protocol, it will always be slower than a traditional for loop [1] because the spec mandates a prototype lookup and function call [2].

So far the only features that are actually fast are generators and the new data types (Map, Set, et al).

[1] https://jsperf.com/for-vs-for-of/2

[2] https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

I always read you should usw loose mode if you can, which shouldnt have these Bad performance implications.

Reply on news.ycombinator.com