Re:Making WebAssembly a first-class language on the Web
by hinkley on Wednesday March 11, 2026 @04:35PM
(#47341208)
I’m wondering if the recent improvements in sending objects through sendMessage in v8 and Bun change the math here enough to be good enough.
SendMessage itself is frustratingly dumb. You have excessively bit fiddly or obnoxiously slow as your options. I think for data you absolutely know you’re sending over a port there should be an arena allocator so you can do single copy sends, versus whatever we have now (3 copy? Four?). It’s enough to frustrate use of worker threads for offloading things from the event loop. It’s an IPC wall, not a WASM wall.
Instead of sending bytes you should transfer a page of memory, or several.
Re:Making WebAssembly a first-class language on the Web
by nneonneo on Wednesday March 11, 2026 @08:06PM
(#47344389)
Your comment - and your last two comments too - all sound very LLM-written. Using an LLM for commenting is explicitly against the site rules (https://news.ycombinator.com/newsguidelines.html#generated).
Re:Making WebAssembly a first-class language on the Web
by thezipcreator on Thursday March 12, 2026 @12:56AM
(#47346639)
webassembly components use a borrow checking model[1], so I assume that would be used to manage DOM components?
I'm not exactly sure how this works when binding it to GC languages.
[1] https://component-model.bytecodealliance.org/design/wit.html...
Re:Making WebAssembly a first-class language on the Web
by pjmlp on Thursday March 12, 2026 @04:21AM
(#47347911)
Proving the point of how it is dominated by Rust folks.
Maybe they should have spent some time wondering how previous component models work, e.g. COM, CORBA, RMI, .NET Remoting,....
Re:Making WebAssembly a first-class language on the Web
by davexunit on Thursday March 12, 2026 @07:25AM
(#47349169)
This is my main confusion, too! I have an existing Wasm GC language implementation and I'm not sure how to reconcile it with the component model.
Re:Making WebAssembly a first-class language on the Web
by thezipcreator on Thursday March 12, 2026 @03:08PM
(#47355628)
I would think you could treat it as a normal GC reference and then just drop the resource when the GC collects the object.
The 45% overhead reduction in the Dodrio experiment by skipping the JS glue is massive. But I'm curious about the memory management implications of the WebAssembly Component Model when interacting directly with Web APIs like the DOM.
If a Wasm Component bypasses JS entirely to manipulate the DOM, how does the garbage collection boundary work? Does the Component Model rely on the recently added Wasm GC proposal to keep DOM references alive, or does it still implicitly trigger the JS engine's garbage collector under the hood?
Really excited to see this standardize so we can finally treat Wasm as a true first-class citizen.