4 ms·

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 migh

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.
        xigoi 7mo ago
        > 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.
        flohofwoe 7mo ago
        > 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.
        xigoi 7mo ago
        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.
- dcminter 7mo ago
  > 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?
  - flohofwoe 7mo ago
    > 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.

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.
      - xigoi 7mo ago
        > 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.
        flohofwoe 7mo ago
        > 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.
        xigoi 7mo ago
        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.
dcminter 7mo ago
> 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?
- flohofwoe 7mo ago
  > 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.