> But WASM is a virtual instruction set for the browser
Depends on how you look at it. WASM itself doesn't have any browser specific features (and on purpose), it's a universal bytecode VM designed with strict sandboxing in mind.
You can manipulate the DOM from WASM by calling through a Javascript shim with very little overhead, same as it works for calling into other browser APIs like WebGL, WebGPU or WebAudio.
It just doesn't make all that much sense since WASM doesn't bring any benefit compared to manipulating the DOM via Javascript. Any theoretical performance advantage is pointless because the entire architecture of the DOM is slow by design.
But if you still want to do it, there are helpers like the Rust web_sys crate:
> Depends on how you look at it. WASM itself doesn't have any browser specific features (and on purpose), it's a universal bytecode VM designed with strict sandboxing in mind.
I know, but other than being able to run it in the browser, does WASM have any other benefits over compiling into C, LLVM, etc?
Firefox has C/C++ libraries compiled into WASM which is then compiled into native code. The end result is that the library is sandboxed into its own memory region.
Depends on how you look at it. WASM itself doesn't have any browser specific features (and on purpose), it's a universal bytecode VM designed with strict sandboxing in mind.
You can manipulate the DOM from WASM by calling through a Javascript shim with very little overhead, same as it works for calling into other browser APIs like WebGL, WebGPU or WebAudio.
It just doesn't make all that much sense since WASM doesn't bring any benefit compared to manipulating the DOM via Javascript. Any theoretical performance advantage is pointless because the entire architecture of the DOM is slow by design.
But if you still want to do it, there are helpers like the Rust web_sys crate:
https://rustwasm.github.io/wasm-bindgen/api/web_sys/
Here's a simple DOM hello world:
https://rustwasm.github.io/wasm-bindgen/examples/dom.html