Hacker News Reader

Comment by flohofwoe | Hacker News Reader

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.

View on HN

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.

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.

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?

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

Here's a simple DOM hello world:

https://rustwasm.github.io/wasm-bindgen/examples/dom.html

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

Mainly security related guarantees, plus it can run effectively anywhere with the same guarantees in all those environments

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

Reply on news.ycombinator.com