When Is WebAssembly Going to Get DOM Support? • Hacker News Board

Re: When Is WebAssembly Going to Get DOM Support?

#31

Post by hardwaresofton » Wed, Jul 23, 2025, 9:24 AM UTC

Disclaimer: I work on Jco, one of the user-facing Bytecode Alliance WASM JS ecosystem projects

Just a note, but there is burgeoning support for this in "modern" WebAssembly:

https://github.com/bytecodealliance/jco/tree/main/examples/c...

If raw WebIDL binding generation support isn't interesting enough:

https://github.com/bytecodealliance/jco/blob/main/packages/j...

Support is far from perfect, but we're moving towards a much more extensible and generic way to support interacting with the DOM from WebAssembly -- and we're doing it via the Component Model and WebAssembly Interface Types (WIT) (the "modern" in "modern" WebAssembly).

What's stopping us the most from being very effective in browsers is the still-experimental browser shim for components in Jco specifically. This honestly shouldn't be blocking us at this point but... It's just that no one has gotten around to improving and refactoring the bindings.

That said, the support for DOM stuff is ready now (you could use those WIT interfaces and build DOM manipulating programs in Rust or TinyGo or C/C++, for example).

P.S. If you're confused about what a "component" is or what "modern" WebAssembly means, start here:

https://component-model.bytecodealliance.org/design/why-comp...

If you want to dive deeper:

https://github.com/WebAssembly/component-model

Re: When Is WebAssembly Going to Get DOM Support?

#32

Post by jagged-chisel » Wed, Jul 23, 2025, 9:25 AM UTC

Interop with JS APIs is a requirement. Therefore, glue code is a requirement. If we’re not going to get direct access to the DOM, can we at least get the ability to just list the JS functions that our wasm will call? Of course the list will be bundled with (compiled into) the wasm blob, and whether it’s literally a text list or something like a registration call naming those JS functions, I am agnostic about. Everyone having to write all their own glue[*] is just nuts at this point.

[*]Yeah, the toolchains help solve this a bit, but it still makes me ship JS and wasm side-by-side.

Re: When Is WebAssembly Going to Get DOM Support?

#33

Post by serbuvlad » Wed, Jul 23, 2025, 9:44 AM UTC

boomskats wrote: post #25

BlackFly wrote: post #4

Earlier quoted context omitted.

My reading of it is that the people furthering WASM aren't really associated with just browsers anymore and they are building a whole new VM ecosystem that the browser people aren't interested in. This is just my take since I am not internal to those organizations. But you have the whole web assembly component model and browsers just do not seem interested in picking that up at all. So on the one side you have organi…

> So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access I don't think this is entirely fair or accurate. This isn't how Wasm runtimes work. Making it possible for the sandbox to explicitly request specific resource access is not quite the same thing as what you're imply…

> The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial.

What are you talking about? Alpine container image is If a service has a multi-gig container, that is for other stuff than the Docker overhead itself, so would also be a multi-gig app for WASM too.

Also, Docker images get overlayed. So if I have many Go or Rust apps running on Alpine or Debian as simple static binaries, the 5MB/30MB base system only exists once. (Same as a wasmtime binary running multiple programs).

Re: When Is WebAssembly Going to Get DOM Support?

#34

Post by xscott » Wed, Jul 23, 2025, 9:44 AM UTC

jagged-chisel wrote: post #32

Interop with JS APIs is a requirement. Therefore, glue code is a requirement. If we’re not going to get direct access to the DOM, can we at least get the ability to just list the JS functions that our wasm will call? Of course the list will be bundled with (compiled into) the wasm blob, and whether it’s literally a text list or something like a registration call naming those JS functions, I am agnostic about. Everyon…

> If we’re not going to get direct access to the DOM, can we at least get the ability to just list the JS functions that our wasm will call?

You mean like a list of JS functions that are imported into the Wasm binary? This has been there since day one:

    (module
        ...
        (import "env" "foo" (func (;0;) (type 1)))
        (import "env" "bar" (func (;1;) (type 2)))
        ...
    )

> Everyone having to write all their own glue[*] is just nuts at this point.

Did you mean for the specific programming language you use? If so then that seems like a problem for the language implementor, not a problem with Wasm. Rust has wasm bindgen, Emscripten has their thing, and so on.

Re: When Is WebAssembly Going to Get DOM Support?

#35

Post by wongarsu » Wed, Jul 23, 2025, 9:45 AM UTC

flohofwoe wrote: post #24

criticalfault wrote: post #22

I've been reading about this for a while. Will it. Won't it. Does anybody know why is it such a big problem to add dom access to wasm? In worst case, we should have a second option to Js (which is not typescript - typescript is just a lipstick on a pig). If wasm is not it, why not something different? Having dart in would be great.

> Does anybody know why is it such a big problem to add dom access to wasm? Well, the article does a pretty good job of answering this specific question ;)

Does it?

It gives good reasons why we can't have specific parts. Having the JavaScript Standard library in WebAssembly would be hard (was anyone actually asking for that?), and some of the modern APIs using promises or iterators wouldn't have a clear mapping. Also not everything could be zero-copy for every language

But the article doesn't do a very good job explaining why we can't have some dom access, at least for the 90% of DOM APIs not using JavaScript-specific features.

Most of the argument boils down to "you shouldn't want direct DOM access, because doing that would be work for these people, and we can instead have those other people do lots of work making the JavaScript bridge less painful. And anyways it's not clear if having these people make proper APIs would actually result in faster code than having those people do a separate sophisticated toolchain for each language"

It reads very much like a people and resource allocation problem rather than a technical challenge

Re: When Is WebAssembly Going to Get DOM Support?

#36

Post by baudaux » Wed, Jul 23, 2025, 9:48 AM UTC

I am adding a WASI runtime (0.1 and 0.2) in https://exaequos.com, an OS running in the web browser. What would be a good DOM api ?

Re: When Is WebAssembly Going to Get DOM Support?

#37

Post by lucideer » Wed, Jul 23, 2025, 9:52 AM UTC

I don't think I want WebAssembly to have DOM support.

Would it be nice? Yes. But.

Every added feature is a trade-off between need -vs- outlay, overhead, complexity & other drawbacks. In order to justify the latter things, that "need" must be significant enough. I'd like to have DOM, but I don't feel the need is significant.

Some thoughts on use-cases:

1. "Inactive" or "in-instance" DOM APIs for string parsing, document creation, in-memory node manipulation, serialisation: this is all possible today in WASM with libraries. Having it native might be cool but it's not going to be a significantly different experience. The benefits are marginal here.

2. "Live / active" or "in-main-thread" direct access APIs to manipulate rendered web documents from a WASM instance - this is where the implementation details get extremely complex & the security surface area starts to really widen. While the use-cases here might be a bit more magical than in (1), the trade-offs are much more severe. Even outside of security, the prospect of WASM code "accidently" triggering paints, or slow / blocking main thread code hooked on DOMMutation events is a potential nightmare. Trade-offs definitely not worth it here.

Besides, if you really want to achieve (2), writing an abstraction to link main-thread DOM APIs to WASM postMessage calls isn't a big lift & serves every reasonable use-case I can think of.

Re: When Is WebAssembly Going to Get DOM Support?

#38

Post by Surac » Wed, Jul 23, 2025, 9:53 AM UTC

i miss the times where computers where used to solve problem. Nowerdays people MAKE there problems themself by layering thousands of apis over each other and calling back and forth milions of times. no wonder computer are not getting faster.

Re: When Is WebAssembly Going to Get DOM Support?

#39

Post by flohofwoe » Wed, Jul 23, 2025, 10:02 AM UTC

wongarsu wrote: post #35

flohofwoe wrote: post #24

Earlier quoted context omitted.

> Does anybody know why is it such a big problem to add dom access to wasm? Well, the article does a pretty good job of answering this specific question ;)

Does it? It gives good reasons why we can't have specific parts. Having the JavaScript Standard library in WebAssembly would be hard (was anyone actually asking for that?), and some of the modern APIs using promises or iterators wouldn't have a clear mapping. Also not everything could be zero-copy for every language But the article doesn't do a very good job explaining why we can't have some dom access, at least for…

> at least for the 90% of DOM APIs not using JavaScript-specific features

The DOM is a Javascript API, so it uses 100% Javascript-specific features (every DOM manipulation requires accessing JS objects and their properties and lots of those properties and function args are Javascript strings) - none of those map trivially to WASM concepts.

It's a bit like like asking why x86 assembly code doesn't allow "C++ stdlib access", the question doesn't even make much sense ;)

Re: When Is WebAssembly Going to Get DOM Support?

#40

Post by wongarsu » Wed, Jul 23, 2025, 10:13 AM UTC

flohofwoe wrote: post #39

wongarsu wrote: post #35

Earlier quoted context omitted.

Does it? It gives good reasons why we can't have specific parts. Having the JavaScript Standard library in WebAssembly would be hard (was anyone actually asking for that?), and some of the modern APIs using promises or iterators wouldn't have a clear mapping. Also not everything could be zero-copy for every language But the article doesn't do a very good job explaining why we can't have some dom access, at least for…

> at least for the 90% of DOM APIs not using JavaScript-specific features The DOM is a Javascript API, so it uses 100% Javascript-specific features (every DOM manipulation requires accessing JS objects and their properties and lots of those properties and function args are Javascript strings) - none of those map trivially to WASM concepts. It's a bit like like asking why x86 assembly code doesn't allow "C++ stdlib ac…

I wouldn't call having objects and properties Javascript-specific. The article details how they were initially written with support by both Java and JavaScript in mind. Now WASM isn't object oriented like Java or JavaScript, but the concept of objects maps very cleanly to the concept of structs, member functions to simple functions that get the struct as first parameter (optionally with an indirection through a virtual function table) and properties to getter/setter functions. I suppose you would have to specify a struct memory layout for the purpose of a WASM DOM API, which may or may not be zero-copy for any given language.

Or is there something in the browser architecture that requires them to be JavaScript objects with the memory layout of the JavaScript engine, rather than just conceptually being objects?