Item — HN Reader

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.

1 comments

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.