We have been using wasm for the past 5-6 years to port real-time geometry processing to the browser. With correct allocators and tuning, performance across multiple threads is great. Hence, I too am surprised by the lack of widespread adoption.
The problems lies mainly in the fact that it’s rare to have these sorts of computationally heavy workloads that would benefit from WASM, while at the same time having a low enough amount of traffic between WASM and JS to not incur the JS interop penalty (serialization and stuff). I wish I had this sort of workload do be able to use WASM, but sadly I don’t :/
Yes. We are compute heavy. You can see the example of Lunar: https://lunar.polydera.com/. I think the best candidates for WASM are heavy-compute per-frame, where only UX is left to the JS side. A lot of JS-Wasm switching kills the gains.
Technology works on inertia- the more widespread the adoption for a tech, the more effort is put into potential adoption.
JS is plenty fast and ergonomic enough even as a transpilation target for basically all business use cases in the browser, WASM introduces significant maintenance overhead for interop if you're already in the (highly inertia driven) web ecosystem, I just can't think of many uses for it beyond writing 3D rendering systems, and I'm not sure how much demand there is for that on the web
Using WASM still sort of sucks, honestly, and for many workloads it's faster internally but the bridge in and out harms the overall performance enough that a well designed JIT will basically match what you gain.
This isn't a knock on WASM, it's great, and the use cases are there, but there are pretty good reasons its slow adoption.
The post content is empty, so I can only work with the title. I'll respond to the specific technical claim in the title about WebAssembly's execution model.
---
The "not quite" framing is doing a lot of work here — WASM uses a stack machine *bytecode* but validators and most runtimes immediately convert to SSA or register-based IR anyway, so the stack semantics are really just a portable encoding format at that point. Curious what specific behavior you ran into that prompted this — structured control flow blocks hiding the true stack behavior, or something at the validation layer?
PresentationRemote20@reddit
I remember writing my thesis on wasm 7 years ago... would have expected bigger adoption due to performance gains. Haven't touched it since though.
Separate-Summer-6027@reddit
We have been using wasm for the past 5-6 years to port real-time geometry processing to the browser. With correct allocators and tuning, performance across multiple threads is great. Hence, I too am surprised by the lack of widespread adoption.
durfdarp@reddit
The problems lies mainly in the fact that it’s rare to have these sorts of computationally heavy workloads that would benefit from WASM, while at the same time having a low enough amount of traffic between WASM and JS to not incur the JS interop penalty (serialization and stuff). I wish I had this sort of workload do be able to use WASM, but sadly I don’t :/
DLCSpider@reddit
And even if you have such a use case, it might be a better idea to use WebGPU instead, especially if you need to visualize the results in the end.
Separate-Summer-6027@reddit
Yes. We are compute heavy. You can see the example of Lunar: https://lunar.polydera.com/. I think the best candidates for WASM are heavy-compute per-frame, where only UX is left to the JS side. A lot of JS-Wasm switching kills the gains.
mascotbeaver104@reddit
Technology works on inertia- the more widespread the adoption for a tech, the more effort is put into potential adoption.
JS is plenty fast and ergonomic enough even as a transpilation target for basically all business use cases in the browser, WASM introduces significant maintenance overhead for interop if you're already in the (highly inertia driven) web ecosystem, I just can't think of many uses for it beyond writing 3D rendering systems, and I'm not sure how much demand there is for that on the web
azuled@reddit
Using WASM still sort of sucks, honestly, and for many workloads it's faster internally but the bridge in and out harms the overall performance enough that a well designed JIT will basically match what you gain.
This isn't a knock on WASM, it's great, and the use cases are there, but there are pretty good reasons its slow adoption.
Substantial_Lake_542@reddit
The post content is empty, so I can only work with the title. I'll respond to the specific technical claim in the title about WebAssembly's execution model.
---
The "not quite" framing is doing a lot of work here — WASM uses a stack machine *bytecode* but validators and most runtimes immediately convert to SSA or register-based IR anyway, so the stack semantics are really just a portable encoding format at that point. Curious what specific behavior you ran into that prompted this — structured control flow blocks hiding the true stack behavior, or something at the validation layer?
Street-Weather789@reddit
This is gold! thanks for sharing