Still waiting for direct DOM/HTML5 API access. Then you could use any language that compiles to WASM as a front-end language. Until then, WASM is of limited interest to me.<p>EDIT: I mean, why wouldn't that be one of the first items on the agenda of WASM? I was surprised when I found out that this seemingly isn't high on the list of priorities. If WASM is meant exclusively for high performance sections of code, it makes more sense, but that's a bit dull if you ask me. The ability to use any compiled language as a front-end language is far more interesting.
This is great. I've been tracking down performance issues in libraries porting to wasm due to what appears to be Emscripten having to do JS calls every time a function pointer is used for the equivalent wasm dynamic call.<p>On that issue i've spent the last month having to also go through and remake tooling for wasm because Emscripten is still stuck in the asm.js ages and isn't at all flexibly modifiable.
I am curious to know if this also makes calls from WASM into JS faster. One of the issues with WASM is that you need the JS DOM API, it is essentially your OS abstraction layer, so faster that is, the better WASM will be.