Comment by yoshuaw

4 days ago

If you want compilers to be able to natively target browsers and access the browser DOM APIs, then you need to define some kind of contract between browsers and compilers on how to call APIs in one from the other. That is what the Wasm Component Model provides.

Perhaps some people are happy to keep the status quo where each call between Wasm and the browser needs to roundtrip through a JS glue layer. But personally I'm excited about a future where that is no longer needed.

From what I've been reading so far the component model in browsers cannot eliminate the JS glue layer, it can at most auto-generate and hide the JS shim to some extent (but that's nothing that can't be done without the component model, and with currently solutions you'll also usually don't need to deal with the JS shim, the various compiler toolchains will do that for you, e.g. Emscripten).

The only advantage you'll get is slightly faster string marshalling, which admittedly is important for DOM access, since the DOM is an extremely string heavy API.

Eliminating the glue layer completely would only be possible if the browser offers a separate 'WASM API' for each web API, but this is very unlikely to happen.