upvote

points

by tomhow5 hours ago |
comments
upvoteby flohofwoe5 hours ago|
[-]
It's still not a great idea IMHO ;)

(there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837)

E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM.

E.g. if I mainly work with web APIs like WebGL2, WebGPU or WebAudio I seriously doubt that the component model approach will cause a 2x speedup, the time spent in the JS shim is already negligible compared to the time spent inside the API implementations, and I don't see how the component model can help with the actually serious problems (like WebGPU mapping GPU buffers into separate ArrayBuffer objects which need to be copied in and out of the WASM heap).

It would be nice to see some benchmarks for WebGL2 and WebGPU with tens-of-thousands of draw calls, I seriously doubt there will be any significant speedup.

reply
upvoteby eqrion4 hours ago|
parent|
next
[-]
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.

reply
upvoteby glenstein3 hours ago|
parent|
prev|
next
[-]
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.

reply
upvoteby flohofwoe3 hours ago|
parent|
next
[-]
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/

reply
upvoteby feznyng3 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby tadfisher3 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby pjmlp1 hours ago|
parent|
prev|
[-]
Except that the Web is basically ChromeOS Platform nowadays, thanks to all those folks targeting only Chrome, complaining about Safari, and shipping Elecron crap.
reply
upvoteby JoshTriplett3 hours ago|
parent|
prev|
next
[-]
> 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.

reply
upvoteby dbdr3 hours ago|
parent|
prev|
next
[-]
If it "only" speeds up DOM access, that's massive in itself. DOM is obviously a crucial element when running inside a browser.
reply
upvoteby nilslice45 minutes ago|
parent|
prev|
[-]
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.

reply