
Making calls to WebAssembly fast and implementing anyref - ag_dubs
https://blog.benj.me/2018/07/04/mozilla-2018-faster-calls-and-anyref/
======
ThJ
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.

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.

------
devwastaken
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.

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.

------
Game_Ender
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.

~~~
bnjbvr
We've had optimizations to make wasm -> JS calls fast for a long time, and
they became even slightly faster (around 10 or 15%) last year. There is a
proposal to add DOM integration within wasm, so one could import DOM functions
in wasm and call them directly (from wasm to C++, without a "trampoline" in
JS).

------
btown
Is there documentation on what Chrome/v8 currently does here? Could a similar
optimization be ported over?

