Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Road to the WASM Component Model 1.0

bytecodealliance.org

Post reply on HN
Print view View original

101–110 of 111 posts

Re: The Road to the WASM Component Model 1.0

#101

Post by flohofwoe »

yoshuaw wrote: post #99
flohofwoe wrote: post #25

> 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 wi…

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…

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.

Re: The Road to the WASM Component Model 1.0

#102

Post by yoshuaw »

flohofwoe wrote: post #101
yoshuaw wrote: post #99

Earlier quoted context omitted.

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…

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…

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

Re: The Road to the WASM Component Model 1.0

#103

Post by breve »

DarkNova6 wrote: post #50
thefounder wrote: post #4

It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”

I don't get it why you need direct DOM access. Just wrap it in JS calls. It's not like current websites are super fast and creating a wrapper will slow it down unnecessarily.

Direct DOM access from WASM is faster:

https://hacks.mozilla.org/wp-content/uploads/2026/02/Screens...

Re: The Road to the WASM Component Model 1.0

#104

Post by breve »

flohofwoe wrote: post #27
thefounder wrote: post #4

It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”

I'm pretty sure you'll will still need a JS shim to talk to most web APIs. For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header (similar to the old 'use asm' for asm.js) as shim, but the JS shim is still there. The component model can marshal 'record types' between different WASM modules, but AFAIK not between a WASM module and a web API.

> For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header

As per the article, that's temporary until Component Model 1.0 is implemented natively in the browser. In the meantime, jco can be used:

> The groundwork for browser implementations is being laid today: jco’s transpile command already converts any component into equivalent core Wasm and JavaScript glue, making components runnable in any browser without native support.

That's no longer needed once native support is there.

Re: The Road to the WASM Component Model 1.0

#105

Post by breve »

dfabulich wrote: post #85
tpm wrote: post #73

Earlier quoted context omitted.

One could write a js-less DOM impl I think.. neither Chrome nor Firefox itself is written in js unlike big parts of Linux that are indeed written in C. Explorer shipped with vbscript as a language that can manipulate the DOM. The really big issue in this case is network effect, which is why I hope something can come out from the momentum building behind WASM.

One couldn't, because you'd need to standardize a JS-less DOM, which requires one to persuade Apple, Google, Microsoft, and Mozilla to agree on a new standard for a JS-less DOM API. The DOM API is currently defined as a JS API, including JS strings, JS objects + properties, JS Exceptions, JS Promises, JS garbage collection, and on and on and on. The effort to get all the browsers to agree to standardize a new JS-less…

They're doing it already:

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

Re: The Road to the WASM Component Model 1.0

#106

Post by breve »

shevy-java wrote: post #5

WASM first appeared in 2017. It still hasn't really reached a breakthrough. Billions use HTML+CSS+JavaScript. Who really uses WASM? There are of course users, but very, very few in absolute numbers. Many projects are not web-based really. For Autodesk Fusion, as one example for many, I have some mega-slow application that takes forever to work with in some cases on my laptop (it is not the fastest laptop, but I recen…

> Who really uses WASM?

Everyone who uses Amazon Prime Video: https://www.amazon.science/blog/how-prime-video-updates-its-...

Everyone who uses Google Sheets: https://web.dev/case-studies/google-sheets-wasmgc

Re: The Road to the WASM Component Model 1.0

#107

Post by auggierose »

pjmlp wrote: post #40
auggierose wrote: post #38

Earlier quoted context omitted.

Yes, but inside the browser is a freaking big use case.

Not really, I don't need COM / CORBA on the browser.

Good for you! In other words, you don't write compute heavy applications for the browser?

I never used COM or CORBA, by the way, just too freaking ugly.

Re: The Road to the WASM Component Model 1.0

#108

Post by [deleted] »

tancop wrote: post #14
Panzerschrek wrote: post #12

Earlier quoted context omitted.

> I don't ever want to run untrusted code from the internet outside of a sandbox ever again WASM is great, but I think it's a wrong approach for sandboxing problem. It's technically possible to sandbox native applications (compiled into target machine code) using OS-builtin mechanisms, but it's not done for compatibility reasons, because this is the way things were done last 50 years or so.

sandboxing native apps just gives you security. with wasm you also get a single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification. you dont need to write platform specific code or use third party frameworks.

[deleted]

Re: The Road to the WASM Component Model 1.0

#109

Post by tschneidereit »

jauntywundrkind wrote: post #93
tschneidereit wrote: post #74

Earlier quoted context omitted.

[Creator of the StarlingMonkey JS runtime here] > It works in the browser already, by bundling another browser runtime engine into wasm. Note that that's not how JCO works: JCO unbundles a Component, emitting core wasm modules plus JS glue code. JCO also is a toolchain that can orchestrate turning JS into a Component, and that does bundle a JS runtime (StarlingMonkey), but that's not for running Components in JS/brow…

Apologies for consuming your time unnecsesarily & for misinformation! Mea culpa! Sorry again, & thank you so much for writing in! Oh my gosh. I don't have a good excuse, don't know how I mis-recalled so badly; it has been a year since I looked. My interest has usually been in getting component runtimes going, less so in downcompiling components into a single blob to run (perhaps on the web), but that is still a grevi…

Oh, no worries at all—it happens!

Re: The Road to the WASM Component Model 1.0

#110

Post by zcw100 »

Panzerschrek wrote: post #18
tancop wrote: post #14

Earlier quoted context omitted.

sandboxing native apps just gives you security. with wasm you also get a single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification. you dont need to write platform specific code or use third party frameworks.

> you dont need to write platform specific code You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice. > single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification It has little value. Compiling a separate binary for each OS isn't that hard…

> You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice.

That's a circular argument and "some" is doing a lot of work there. What cross-platform framework would you be referring to?

> It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary.

It my have little value to you but that doesn't mean it has little value to everyone. I don't agree that compiling to multiple architectures is without difficulty and restricting yourself to only popular ones proves the point. What specific "other user-side overhead" would you be referring to? Lots of things aren't strictly necessary, that doesn't imply they're not necessary. Yes, there is a performance cost. Sometimes that cost is worth paying.

Post reply on HN