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.

> 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.

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

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

> 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.

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.

You can access the DOM just fine without having to write any JS, for instance: 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...

> people who never actually used WASM ;)

Fair if you mean me - I've at most toyed with it, but the shim stuff was off-putting.

I'm a backender though, I don't pretend my opinion is of any consequence here.

> Personally I'm not a fan of this

You make it sound like the shim layer is actively desirable - why is that?

> You make it sound like the shim layer is actively desirable - why is that?

More flexibility. For instance even though the 'official' WebGPU shim has the upside that it is compatible with the webgpu.h C API header, it buys that compatibility with some pretty serious performance compromises which can be avoided when using a non-standard JS shim (for instance reading/writing data from/to mapped WebGPU buffers which live in their own ArrayBuffer object, I don't think the WASM Component Model has a solution for such scenarios). The WASM Component Model solution basically has to deal with the exact same problems, but the WebGPU C API will essentially be baked into the browser. I expect though that it will still be possible to write your own specialized JS shim, so it's not a too big of an issue. I would prefer if the WASM peeps first focus on solving other problems which provide more bang for the buck though.

> 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.

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.

The DOM is what you want to interact with most of the time…

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.

> Only for traditional webpages, and for those JS/TS is perfectly fine

I hate JavaScript and don’t want to use it at all. I want WebAssembly to allow me to write “traditional” webpages using a different scripting language.

> I hate JavaScript

...it's just another tool in the programmers toolbox? Right tool for the job etc... Also for anything non-trivial just use Typescript which is actually a decent language.

It’s not the right tool for the job if, for example, you need a tuple-indexed hashmap, which I needed for a web app recently. TypeScript does not help, it’s just a layer on top. Also I hate the inconsistent syntax and the footguns inherited from C, such as fallthrough in switch statements.

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.

> Now it seems the number of people using wasm, is mega-low.

What are you basing this on? Got a source?

“seems” doesn’t need a source

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).