Hacker News new | ask | show | jobs
by flohofwoe 23 hours ago
> The Component Model can’t formally reach 1.0 without native implementation in at least two browser engines.

I don't quite understand why the Component Model is now suddenly a browser thing, and on top something that needs to be implemented natively in browsers instead of a convention between different compiler toolchains.

Keep that boondoggle in WASI and the Bytecode Alliance. WASM in the browser works just fine without the added runtime complexity.

2 comments

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 won't eliminate the JS glue layer, it can at most hide it to some extent. The advantage you'll get is slightly faster string marshalling.

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.

Because no one cares about yet another CORBA, gRPC is good enough, and going forward stuff like MCP and A2A are way more relevant even, so they need the browser for having any use case at all that people would actually care about.

Otherwise in a couple of years no one would care Component Model ever existed.