Hacker News Reader

Comment by klodolph | Hacker News Reader

…if there’s a “why”, maybe it’s because WASM can’t interact with the DOM and the debugging experience isn’t very good.

The DOM API is defined as a JavaScript API. The browser, JavaScript, and the DOM API have been evolving in parallel for over 20 years. If you want to interact with the DOM from WASM, what you can do is write a function in JavaScript that interacts with the DOM, and then import that function into your WASM module.

At least for now.

View on HN

To further explain: the standard WASM ABI is essentially just a C ABI, so you can pass integers and pointers around, but you can't do much more; anything more complex needs to be built on top of that, which precludes binding to the DOM API directly.

The existing workarounds for this glue the JS DOM API to the guest language through glue on both sides, but this means that you have to pay the penalty of marshalling through JS for every single call you make.

There's a solution in the works to make direct interaction possible, but it's proven to be quite challenging to finalise: essentially, you need a high-level ABI that can provide a safe and fast interface between the host and whatever guest language, and defining that in a way that makes everyone happy is non-trivial.

For more information, see the Component Model [0] and WIT [1]; the idea is that you will eventually be able to compile your WASM to WASM Components, which can then interface with the host (or other WASM components) through the WIT IDL, including interacting with the browser's DOM.

[0]: https://github.com/WebAssembly/component-model [1]: https://github.com/WebAssembly/component-model/blob/main/des...

> you can pass integers and pointers around

No, not even that (the second thing, passing pointers)! WASM has a different address space (starting from 0), effectively indexing into the WASM module's linear memory. A pointer/reference from the outside env can not be dereferenced from within the WASM bytecode.

The multiple linear memory proposal can circumvent this (allowing you to build something somewhat similar to a simple MMU/address translation engine), but language support for that feature is sparse (AFAIK, Rust does not expose any way to access a different than the default linear memory for example).

There is various hacks around it, but sharing memory block-wise between WASM and outside env is involved already.

Yes, sorry, I should have clarified: pointers to the WASM memory, not host memory. You need to copy data into the memory in order to use it.

> The DOM API is defined as a JavaScript API.

It's defined via WebIDL (https://webidl.spec.whatwg.org/) which is theoretically language agnostic, but practically speaking the primary implementation target is JavaScript.

Reply on news.ycombinator.com