Hacker News Reader

Comment by thefounder | Hacker News Reader

It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”

View on HN

I don't get it why you need direct DOM access. Just wrap it in JS calls. It's not like current websites are super fast and creating a wrapper will slow it down unnecessarily.

The article cites the research that JS wrapping of DOM calls slows things down by 50%.

Just to be clear: It slows down the overhead of a function call by 50%. It doesn't slow down the function implementation which takes a very large percentage of the time.

Direct DOM access from WASM is faster:

https://hacks.mozilla.org/wp-content/uploads/2026/02/Screens...

Can I just say fuck JavaScript so we can stop mentioning this time and time again ?

I'm pretty sure you'll will still need a JS shim to talk to most web APIs. For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header (similar to the old 'use asm' for asm.js) as shim, but the JS shim is still there. The component model can marshal 'record types' between different WASM modules, but AFAIK not between a WASM module and a web API.

> For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header

As per the article, that's temporary until Component Model 1.0 is implemented natively in the browser. In the meantime, jco can be used:

> The groundwork for browser implementations is being laid today: jco’s transpile command already converts any component into equivalent core Wasm and JavaScript glue, making components runnable in any browser without native support.

That's no longer needed once native support is there.

we still need js shim for dom access :(

Asking for 0% js 100% wasm website is like wanting a C-free linux distro

One could write a js-less DOM impl I think.. neither Chrome nor Firefox itself is written in js unlike big parts of Linux that are indeed written in C. Explorer shipped with vbscript as a language that can manipulate the DOM.

The really big issue in this case is network effect, which is why I hope something can come out from the momentum building behind WASM.

One couldn't, because you'd need to standardize a JS-less DOM, which requires one to persuade Apple, Google, Microsoft, and Mozilla to agree on a new standard for a JS-less DOM API.

The DOM API is currently defined as a JS API, including JS strings, JS objects + properties, JS Exceptions, JS Promises, JS garbage collection, and on and on and on.

The effort to get all the browsers to agree to standardize a new JS-less DOM API would take years; none of the browser vendors even want to begin that conversation today.

They're doing it already:

https://hacks.mozilla.org/2026/02/making-webassembly-a-first...

Web API is described in WebIDL, and javascript has its own approach to consume these interfaces.

The issue is that many modern DOM APIs assume js semantics and types (eg promises, iterables, etc) so you need to "reimplement" some js semanthic in wasm; sorta like how apple added a few custom instructions on the M1 chip specifically for the type of floating point operation required by js.

Reply on news.ycombinator.com