3 ms·

When I looked into Web Assembly I was surprised to find it doesn't drive the DOM.

flohofwoe 2y ago
I really wonder why the DOM always comes up. The DOM is just one browser API among many, and WASM is a virtual instruction set. Browser APIs have been designed for Javascript (for better or worse) meaning they work with Javascript objects and properties. WASM isn't Javascript, and it only works with floats and integers, so it needs an FFI layer to talk to browser APIs. In the end, calling from WASM into JS isn't all that different than calling from native machine code into a virtual machine like .NET or the JVM.
- pjmlp 2y ago
  For me the best way to think about WebAssembly, is to use the same approach as to keep a sane NDK experience on Android, write the code in a way that is always called from the host, instead of a interweb from down and upcalls.
- 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...
- skrapion 2y ago
  WASM without DOM would be like if your operating system said "you can write your code in any language, but if you want to output anything to the screen, you need to compile your code as a DLL and call it from a C program." For an assembly language designed to run in the browser, I wouldn't characterize DOM access as "just one of many APIs". DOM access is the most universal need in front end programs.
yencabulator 2y ago
Unfortunately the DOM APIs were specified to have Javascript-specific details in them. As far as I understand it, the best way to access the DOM from WASM would be to define a new WASI Component -compatible API for the DOM. Nobody's done the work yet, and I think the current strategy is to tackle easier APIs first, as WASI might not be good enough to describe the DOM at this time. With a DOM API independent of Javascript, you could have a C/C++/Rust DOM in the host, and C/C++/Rust code inside WASM calling functions on the DOM, without needing to talk about Javascript types in the middle.

I really wonder why the DOM always comes up. The DOM is just one browser API among many, and WASM is a virtual instruction set. Browser APIs have been designed for Javascript (for better or worse) meaning they work with Javascript objects and properties. WASM isn't Javascript, and it only works with floats and integers, so it needs an FFI layer to talk to browser APIs. In the end, calling from WASM into JS isn't all that different than calling from native machine code into a virtual machine like .NET or the JVM.

pjmlp 2y ago
For me the best way to think about WebAssembly, is to use the same approach as to keep a sane NDK experience on Android, write the code in a way that is always called from the host, instead of a interweb from down and upcalls.
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...
skrapion 2y ago
WASM without DOM would be like if your operating system said "you can write your code in any language, but if you want to output anything to the screen, you need to compile your code as a DLL and call it from a C program." For an assembly language designed to run in the browser, I wouldn't characterize DOM access as "just one of many APIs". DOM access is the most universal need in front end programs.

yencabulator 2y ago

Unfortunately the DOM APIs were specified to have Javascript-specific details in them. As far as I understand it, the best way to access the DOM from WASM would be to define a new WASI Component -compatible API for the DOM. Nobody's done the work yet, and I think the current strategy is to tackle easier APIs first, as WASI might not be good enough to describe the DOM at this time. With a DOM API independent of Javascript, you could have a C/C++/Rust DOM in the host, and C/C++/Rust code inside WASM calling functions on the DOM, without needing to talk about Javascript types in the middle.