4 ms·

But WASM is a virtual instruction set for the browser, so wouldn't it be convenient (and maybe fast) to control DOM from it? I guess one can run WASM on server

by kreetx 2y ago

But WASM is a virtual instruction set for the browser, so wouldn't it be convenient (and maybe fast) to control DOM from it? I guess one can run WASM on servers, too, but aren't there plenty of ways there to do it already?

flohofwoe 2y ago
> 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: https://rustwasm.github.io/wasm-bindgen/api/web_sys/ 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 https://rustwasm.github.io/wasm-bindgen/examples/dom.html
- kreetx 2y ago
  > 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?
  - csjh 2y ago
    Mainly security related guarantees, plus it can run effectively anywhere with the same guarantees in all those environments
  - yencabulator 2y ago
    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. https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...

by kreetx 2y ago

flohofwoe 2y ago

> 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: https://rustwasm.github.io/wasm-bindgen/api/web_sys/ 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 https://rustwasm.github.io/wasm-bindgen/examples/dom.html

kreetx 2y ago
> 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?
- csjh 2y ago
  Mainly security related guarantees, plus it can run effectively anywhere with the same guarantees in all those environments
- yencabulator 2y ago
  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. https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...