I think Lemire's measurements are unacceptably lazy. WebAssembly is faster than JavaScript on the right things; there are many measurements showing this. Typically, measurements that show JS on par or beating Wasm either end up falling into microbenchmarking traps (one small, hot loop, something gets deadcode-eliminated), or they end up relying on a particular type of dynamic optimization that Wasm engines don't yet do (inlining, escape analysis).
With SIMD and threads, Wasm can absolutely crush JS performance.
Why would Wasm engines need to do inlining and dead code elimination? My impression was that Wasm is basically native level-code, save for register allocation, and some arch-specific peephole optimizations. Dead code elimination is the job of the C++ compiler.
Generally, I don't disagree, but not all producers are LLVM. And JS inlining is driven by dynamic heuristics, speculatively inlining likely candidates, whereas statically-compiled C++ code generally doesn't have speculative inlining. So a Wasm call_indirect will not get dynamically optimized into a guarded inline.
It's been implemented in browsers for longer than the spec has been out. In fact, one condition of a proposal being merged into the spec is that two production engines must have implemented it.
With SIMD and threads, Wasm can absolutely crush JS performance.
https://www.infoq.com/articles/webassembly-simd-multithreadi...