Re:Making WebAssembly a first-class language on the Web
by eqrion on Wednesday March 11, 2026 @12:57PM
(#47338099)
I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web developers won't need to write WIT and can just use Web API's as if they were a library. But it's early days.
Re:Making WebAssembly a first-class language on the Web
by davexunit on Wednesday March 11, 2026 @02:05PM
(#47339012)
I am excited by the prospect of booting Wasm binaries without any JS glue, but when I've looked at the documentation for the component model and WIT it says that resources are references passed using a borrow checking model. That would be a serious downgrade compared to the GC-managed reference passing I can do today with Wasm GC. Do you know if there are any plans to resolve this mismatch?
Re:Making WebAssembly a first-class language on the Web
by bloppe on Thursday March 12, 2026 @08:27PM
(#47359201)
Relevant: https://github.com/WebAssembly/component-model/issues/525
In my experience people are often disappointed by the shared-nothing architecture of the component model. I guess that shared-nothing architecture makes it impossible to properly share GC objects across component boundaries. But they can still be shared across core module boundaries.
Re:Making WebAssembly a first-class language on the Web
by bvisness on Friday March 13, 2026 @07:01PM
(#47371156)
A lot of the time I think you just won’t want to use multiple components. It’s nice to be able to compose them together, I guess, but in general it seems to me that a toolchain will typically just want to generate a single big component so that everything can interact without limits internally.
Re:Making WebAssembly a first-class language on the Web
by j45 on Wednesday March 11, 2026 @03:55PM
(#47340441)
The tooling has been in it's early days for a long time. As quickly as that can improve, so will the uptake. The technology itself is quite capable.
Re:Making WebAssembly a first-class language on the Web
by elestor on Thursday March 12, 2026 @11:35AM
(#47352303)
What do you mean by churn in this context?
Re:Making WebAssembly a first-class language on the Web
by NohatCoder on Thursday March 12, 2026 @12:22PM
(#47353224)
The whole WASM thing just went sideways from the start. It feels like the property of being practically unreadable and unwritable for humans was a design criterium, it is certainly the primary "feature" enabled by the stack approach.
Then there is the single array of memory that makes modern memory allocators not really work, resulting in every WASM compiler scrounging up something that mashes the assumptions of the source language into a single array.
Re:Making WebAssembly a first-class language on the Web
by bvisness on Friday March 13, 2026 @07:03PM
(#47371173)
The “single array of memory” is not the problem; that’s what all these languages already expect. The problem is the lack of meaningful memory APIs, e.g. virtual memory capabilities. I am co-champion of a proposal to fix this but have not been able to prioritize it for a while, unfortunately: https://github.com/WebAssembly/memory-control/blob/main/prop...
The difference in perf without glue is crazy. But not surprising at all. This is one of the things I almost always warn people about, because it's such a glaring foot gun when trying to do cool stuff with WASM.
The thing with components that might be addressed (maybe I missed it) is how we'd avoid introducing new complexity with them. Looking through the various examples of implementing them with different languages, I get a little spooked by how messy I can see this becoming. Given that these are early days and there's no clearly defined standard, I guess it's fair that things aren't tightened up yet.
The go example (https://component-model.bytecodealliance.org/language-suppor...) is kind of insane once you generate the files. For the consumer the experience should be better, but as a component developer, I'd hope the tooling and outputs were eventually far easier to reason about. And this is a happy path, without any kind of DOM glue or interaction with Web APIs. How complex will that get?
I suppose I could sum up the concern as shifting complexity rather than eliminating it.