[atonparker]

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.

[daliwali]

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.

[stymaar]

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.