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.
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.
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...