I agree there are some cases that won't see a huge boost, but also DOM performance is a big deal and bottleneck for a lot of applications.

And besides performance, I think there are developer experience improvements we could get with native wasm component support (problems 1-3). TBH, I think developer experience is one of the most important things to improve for wasm right now. It's just so hard to get started or integrate with existing code. Once you've learned the tricks, you're fine. But we really shouldn't be requiring everyone to become an expert to benefit from wasm.

> DOM performance is a big deal and bottleneck for a lot of applications

What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production.

> But we really shouldn't be requiring everyone to become an expert to benefit from wasm.

If the toolchain does it for them, they don't need to be experts, no more than people need to be DWARF experts to debug native applications.

I agree tools could be a lot better here! But as I think you know, my position is that we can move faster and get better results on the tools side.

> What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production.

any application you use today that is written in JavaScript rendering to the DOM, is much harder to write in not-JavaScript

Slack, Teams, Outlook, Word, OpenAI, Anthropic, Github, Twitter, Instagram (web), Notion, Google Docs, ...

Sorry, I'll ask my question in a better way: what applications written in wasm that exist today would benefit from this?

Now, maybe there aren't many because of performance - maybe they haven't used wasm because it was too slow. But I would appreciate seeing data on that - an application that tried wasm and gave up after seeing the overhead, at the least. But I would also expect to see apps that use wasm even despite some DOM overhead, because of the speedup on non-DOM code - and I'd like to see data on how much DOM overhead they are currently suffering.

I am asking because I'm familiar with a lot of apps ported to wasm, and they don't do this. That may just be because I am seeing one particular slice of the ecosystem! So I am very curious to learn about other parts.

The onboarding cliff is real. I've pointed experienced JS devs at wasm-bindgen docs and watched their eyes glaze over before they've even gotten to the actual interesting part. Most end up cargo-culting a template they found and never really understand what the glue is doing.

Hopefully native component support makes that "aha, I get it now" moment happen earlier.

With Google now pushing developer certification, Android and iOS practically being mandatory for certain basic functions like accessing your bank or certain government services, Webassembly would make web apps first class citizens that aren't subject to mobile operating system lockdown.

Being able to complete on efficiency with native apps is an incredible example of purposeful vision driving a significant standard, exactly the kind of thing I want for the future of the web and an example of why we need more stewards like Mozilla.

FWIW my home computer emulators [1] already run at about the same performance (give or take 5..10% depending on CPU type) in WASM versus their natively compiled counterparts.

Performance is already as good as it gets for "raw" WASM, the proposed component model integration will only help when trying to use the DOM API from WASM. But I think there must be less complex solutions to accelerate this specific use case.

[1] https://floooh.github.io/tiny8bit/

How does WASM solve the platform lockdown problem? That WASM will run in a third-party app that is subject to those restrictions. The system interface exposed within that runtime is still going to be limited in the same way a native app can't get real access to the filesystem, etc.

Removing JS glue doesn't enable anything you couldn't do before. Those banks and governments still need to write the web apps, and they need to uncheck the security box which requires a hardware-attested environment.

Except that the Web is basically ChromeOS Platform nowadays, thanks to all those folks targeting only Chrome, complaining about Safari, and shipping Elecron crap.

If it "only" speeds up DOM access, that's massive in itself. DOM is obviously a crucial element when running inside a browser.

> just to get 2x faster string marshalling

That is a useful benefit, not the only benefit. I think the biggest benefit is not needing glue, which means languages don't need to agree on any common set of JS glue, they can just directly talk DOM.

agreed. no one needs the component model, and it's just a attempt for people to create work for themselves.

especially now with coding agents, the DX they think they are bringing to the table is completely irrelevant.

Your logic is circular though. You are saying that there won't be much speedup for the sort of things people already do in WASM - but the reason they're doing them in WASM is because they're not slowed down too much.

What you don't get much is people doing standard SPA DOM manipulation apps in WASM (e.g. the TodoMVC that they benchmarked) because the slowdown is large. By fixing that performance issue you enable new usecases.

IMHO the bang-for-the-buck proportion isn't right. The core problem is slow string marshalling in the JS shim (because it needs to create a JS string object from an ArrayBuffer slice - where the array buffer is the WASM heap).

Integrating the component model into browsers just for faster string marshalling is 'using cannons to shoot sparrows' as the German saying goes.

If there would be a general fast-path for creating short-lived string objects from ArrayBuffer slices, the entire web ecosystem would benefit, not just WASM code.

Yeah, I don't think it bears out that DOM operation invocations constitute a major bottleneck for a lot of web applications. Certainly the execution of those operations (like layout invalidation and calculation) can be expensive, but those would not benefit. I can't think of applications with a massive amount of DOM calls that would benefit from lower latency.