13 ms·

Well ... that kind of explains why nobody uses wasm. Initially I fell for the hype too. Now it seems the number of people using wasm, is mega-low. It's like th

Well ... that kind of explains why nobody uses wasm. Initially I fell for the hype too. Now it seems the number of people using wasm, is mega-low. It's like the tiniest ever fraction of javascript-knowing folks. And this will probably never change either. I guess it is time to conclude: - wasm will remain a small niche. At the least for the, say, close future. But probably forever.

flohofwoe 7mo ago
This is not specific to WASM, you would have the same problems calling from Rust into any other language through FFI.
- suddenlybananas 7mo ago
  PyO3 is designed in such a way that it's a lot easier to avoid many of these issues I find.
antonvs 7mo ago
> It's like the tiniest ever fraction of javascript-knowing folks. “Javascript-knowing folks” aren’t likely to have much overlap with people who have a need for WASM. It’s a bit confusing because of the history of WASM, but the two are pretty separate at this point. We use WASM to deploy machine learning models in the browser, for example. That’s not something we would have ever considered doing with Javascript.
xigoi 7mo ago
> wasm will remain a small niche. At the least for the, say, close future. But probably forever. I’m still waiting for being able to access the DOM from WebAssembly, so it’s possible to do something useful with it without JavaScript glue code.
- dcminter 7mo ago
  Does anyone know if there's any reasonable timescale likely for this to happen? Last time I looked into the topic it seemed to be completely stalled, but I might well have been looking in the wrong places. To a very casual observer (me) it seems like it ought to be simple, but I expect there are good reasons why it isn't.
  - flohofwoe 7mo ago
    You can access the DOM just fine without having to write any JS, for instance: https://github.com/web-dom/web-dom https://github.com/web-dom/web-dom The JS shim is still there, but it's hidden away from the programmer. For a more direct approach which entirely avoids going through a JS shim: Mozilla is starting to experiment with integrating the WASM Component Model into the browser. Personally I'm not a fan of this because apart from string conversion the JS shim is not the performance bottleneck that people think it is, but at the least it will finally shut up all the 'direct DOM access whining' that shows up in each and every HN thread about WASM from people who never actually used WASM ;) https://hacks.mozilla.org/2026/02/making-webassembly-a-first-class-language-on-the-web/ https://hacks.mozilla.org/2026/02/making-webassembly-a-first...
    - xigoi 7mo ago
      > Personally I'm not a fan of this because apart from string conversion the JS shim is not the performance bottleneck that people think it is A benchmark in the article you linked shows a 2× slowdown.
      - flohofwoe 7mo ago
        This is almost certainly dominated by string conversion which is a worst case scenario, most web APIs are by far not as 'string-heavy' as the DOM.
        xigoi 7mo ago
        The DOM is what you want to interact with most of the time…
        flohofwoe 7mo ago
        Only for traditional webpages, and for those JS/TS is perfectly fine but the web platform is much more than the DOM. Once you build a web app via the DOM any sort of performance doesn't matter anyway because the DOM is slow by design, manipulating the DOM from WASM won't magically make an inherently slow system fast.
matt_kantor 7mo ago
> Now it seems the number of people using wasm, is mega-low. What are you basing this on? Got a source?
- vegabook 7mo ago
  “seems” doesn’t need a source
  - matt_kantor 7mo ago
    It doesn't need one, but I am asking if there is one. Or if there isn't, what else they are basing it on (the answer could be anything from personal anecdotes to actual data; that's what I'd like to know).
pjmlp 7mo ago
If you care about performance on the browser it is easier to reach out to WebGPU compute shaders than dealing with WASM tooling. And if using a GC language, JS/TS isn't really that bad.
hrmtst93837 7mo ago
[flagged]
rho_soul_kg_m3 7mo ago
For me, wasm is a godsend. I sure hope it doens't go away. I can write a reasonably complex GUI with Rust and egui and OpenGL and put it online without having to deal with browser/Javascript/TS nonsense. The only pain points for me, so far, are (1) network and local file access for which I had to write tiny amounts of wrapper JS (2) having to rewrite shaders for OpenGL ES and (3) executor gymnastics for manual cooperative scheduling of some background computations, apparently multithread support isn't quite there yet. Also it works perfectly fine under Firefox, Chromium and even on my cellular telephone (these things have browsers now!) with Vanadium and Firefox mobile.

flohofwoe 7mo ago

This is not specific to WASM, you would have the same problems calling from Rust into any other language through FFI.

suddenlybananas 7mo ago
PyO3 is designed in such a way that it's a lot easier to avoid many of these issues I find.

antonvs 7mo ago

> It's like the tiniest ever fraction of javascript-knowing folks. “Javascript-knowing folks” aren’t likely to have much overlap with people who have a need for WASM. It’s a bit confusing because of the history of WASM, but the two are pretty separate at this point. We use WASM to deploy machine learning models in the browser, for example. That’s not something we would have ever considered doing with Javascript.

xigoi 7mo ago

> wasm will remain a small niche. At the least for the, say, close future. But probably forever. I’m still waiting for being able to access the DOM from WebAssembly, so it’s possible to do something useful with it without JavaScript glue code.

dcminter 7mo ago
Does anyone know if there's any reasonable timescale likely for this to happen? Last time I looked into the topic it seemed to be completely stalled, but I might well have been looking in the wrong places. To a very casual observer (me) it seems like it ought to be simple, but I expect there are good reasons why it isn't.
- flohofwoe 7mo ago
  You can access the DOM just fine without having to write any JS, for instance: https://github.com/web-dom/web-dom https://github.com/web-dom/web-dom The JS shim is still there, but it's hidden away from the programmer. For a more direct approach which entirely avoids going through a JS shim: Mozilla is starting to experiment with integrating the WASM Component Model into the browser. Personally I'm not a fan of this because apart from string conversion the JS shim is not the performance bottleneck that people think it is, but at the least it will finally shut up all the 'direct DOM access whining' that shows up in each and every HN thread about WASM from people who never actually used WASM ;) https://hacks.mozilla.org/2026/02/making-webassembly-a-first-class-language-on-the-web/ https://hacks.mozilla.org/2026/02/making-webassembly-a-first...
  - xigoi 7mo ago
    > Personally I'm not a fan of this because apart from string conversion the JS shim is not the performance bottleneck that people think it is A benchmark in the article you linked shows a 2× slowdown.
    - flohofwoe 7mo ago
      This is almost certainly dominated by string conversion which is a worst case scenario, most web APIs are by far not as 'string-heavy' as the DOM.
      - xigoi 7mo ago
        The DOM is what you want to interact with most of the time…
        flohofwoe 7mo ago
        Only for traditional webpages, and for those JS/TS is perfectly fine but the web platform is much more than the DOM. Once you build a web app via the DOM any sort of performance doesn't matter anyway because the DOM is slow by design, manipulating the DOM from WASM won't magically make an inherently slow system fast.

matt_kantor 7mo ago

> Now it seems the number of people using wasm, is mega-low. What are you basing this on? Got a source?

vegabook 7mo ago
“seems” doesn’t need a source
- matt_kantor 7mo ago
  It doesn't need one, but I am asking if there is one. Or if there isn't, what else they are basing it on (the answer could be anything from personal anecdotes to actual data; that's what I'd like to know).

pjmlp 7mo ago

If you care about performance on the browser it is easier to reach out to WebGPU compute shaders than dealing with WASM tooling. And if using a GC language, JS/TS isn't really that bad.

hrmtst93837 7mo ago

[flagged]

rho_soul_kg_m3 7mo ago

For me, wasm is a godsend. I sure hope it doens't go away. I can write a reasonably complex GUI with Rust and egui and OpenGL and put it online without having to deal with browser/Javascript/TS nonsense. The only pain points for me, so far, are (1) network and local file access for which I had to write tiny amounts of wrapper JS (2) having to rewrite shaders for OpenGL ES and (3) executor gymnastics for manual cooperative scheduling of some background computations, apparently multithread support isn't quite there yet. Also it works perfectly fine under Firefox, Chromium and even on my cellular telephone (these things have browsers now!) with Vanadium and Firefox mobile.