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.
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.
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.
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)
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 {}.
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