Hacker News new | ask | show | jobs
by yoshuaw 12 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.
1 comments
flohofwoe 12 days ago
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.

link
yoshuaw 11 days ago
Mozilla is currently prototyping this in the browser [1] and measured 45% reduced overhead compared to calling DOM APIs through JS glue. The Chrome team has also expressed their interest. That's not a guarantee it will ever land of course; but I'm cautiously optimistic we'll get there eventually.

[1]: https://hacks.mozilla.org/2026/02/making-webassembly-a-first...

link