Benedikt Meurer

The first run is almost completely irrelevant in practice. The common case is that you have webpack driving the build via loaders (i.e. Babel, TypeScript, PostCSS, Prepack, etc.) and those...

I've experimented with different setups, including just benchmarking an actual webpack build with all the loaders you needed for that project. But this usually didn't work out well, partially because...

Since this is designed as strictly output format for tools, I don't think we need any early errors here. They can be reported by the tools and don't add any...

Fail the build step.

Right. Of course browsers cannot blindly trust arbitrary input. Invalid functions can just fail on first invocation.

@tlively I just realized that CodeMirror is missing from the list above. Without CodeMirror support (in the `wast` mode), SIMD instructions syntax highlighting will be wrong/confusing to developers in their...

Definitely. In the meantime Apple created an ES6 benchmark called [ARES-6](http://browserbench.org/ARES-6/), but it is not very representative of real workloads (except for the Babylon case) currently. And it doesn't contain...

There's been a related discussion in https://github.com/nodejs/promises/issues/31 earlier this year, which yielded a couple of interesting improvements and insights. Pinging @nodejs/performance @nodejs/async_hooks

>> I'd like to use this forum to come to an agreement on what the concrete use cases are (at least estimate that), which aspects of the performance matter the...

@AndreasMadsen Thanks for the feedback, that's very interesting. These seem to be more on the feature request side. > I think in many cases it is straightforward to know when...