Hacker News Reader

Comment by jacobolus | Hacker News Reader

I’ve been staying away from most new ES6 features because when I tested them a year ago (either transpiled or with native support) they were slow as molasses in every browser I tried. Hopefully having some better benchmarks gets Firefox and Chrome developers to also get to work on this.

View on HN

Yeah a good idea. I was thinking we could make a similar table to compat-table (maybe using six-speed or this) that we could use as data to https://github.com/babel/babel-preset-env so that Babel could compile based on the compiled speed relative to native support. Haven't really looked into in much yet (if anyone is interested, let me know)

Basically, if there is native support but it's not as fast as compiled/polyfilled we could continue to compile.

TypeScript is a good solution for this. I use ES2015+ features this way regularly and they perform great. I target ES5 so they are transpiled at build time, and as an added bonus I get async/await which is seriously a life saver in certain situations.

Edit... I work at Microsoft (I'm supposed to disclose this), but not on the TypeScript team.

Do you mean that you saw actual differences when using Javascript in a normal website? Or that they were slower than the alternatives in a synthetic benchmark? It would be really surprising that those were the performance bottlenecks.

Native ES6 is faster in WebKit than polyfill/transpiled.

Yes, but sticking to old-school Javascript features was dramatically faster than either.

Not necessarily. Map/Set is a counterexample. There’s no substitute for the JIT knowing how to reason about the internal aliasing properties of your hash table implementation.

We’ll keep working on more optimizations for ES-6 so there will be more counter examples.

But ES6 Map/Set is almost useless as it has no custom hash nor equality function. The key is either numeric, string, or object identity, not anyway better than the builtin {}.

I've found them to be useful when I write ES6 code. I agree that custom hash and equality functions would make these classes a lot better.

I agree too. I wonder if this has been discussed at TC39.

To be clear, do you mean that Map/Set is faster than {} even for plain idiomatic hashes with string keys (as opposed to pathological cases)?

When I last tested in other JS engines I found plain {} hashes were still moderately faster. (Haven't tried Safari since it doesn't support what I've been working on)

No, I don't mean that. If you're using string or integer keys, then I think that {} still have a perf advantage.

Pretty much the only thing I've had problems with is generators. Regenerator runtime is so slow. Especially when making a bunch of calls with async/await

Reply on news.ycombinator.com