The WASM VM doesn't have any (direct) access to the DOM, so there's no code you can write in it that would affect the DOM.
There's a way to make JS functions callable by WASM, and that's how people build a bridge from WASM to the DOM, but it involves extra overhead versus some theoretical direct access.
That's like saying WASM doesn't have a direct way to allocate memory or print to the console. Of course it doesn't, it doesn't have access to anything, that's the whole point.
I think a good analogy would be between user-space and kernel-space code.
It's just weird that by this logic, JavaScript - the more high-level, less typesafe and less performant language - would be the kernel, while performance-optimized WASM code would be the userspace program.
Thanks for the clarification. So if I understand correctly - when using WASM you interface to web things through JS forcing the user to always need JS in the stack when e.g. they may want to just use Rust or Go. My first thought would be modules that are akin to a syscall interface to a DOM "device" exposed by the VM.
There's a way to make JS functions callable by WASM, and that's how people build a bridge from WASM to the DOM, but it involves extra overhead versus some theoretical direct access.