`rustup target add wasm32-unknown-unknown`
`cargo build --target=wasm32-unknown-unknown`
Is all you need to compile a Rust library to a `.wasm` file. (almost, you also need a setting in Cargo.toml: [lib] crate-type = ["cdylib", "rlib"] )
In the browser you can get access to DOM apis via web-sys.
The documentation has quite a lot of examples and info: https://rustwasm.github.io/wasm-bindgen/web-sys/index.html
wasm-pack (https://github.com/rustwasm/wasm-pack) makes building code for the browser easy.
Wow! The last time I looked, doing anything remotely like this was a gigantic pain, in any language.
I guess it's finally time for me to get around to learning Rust.
Then D is quite easy to use (LDC alongside betterC mode, runtime is still not fully ported).
Followed by TinyGo, Rust, C#, Nim.
I would leave Emscripten, C and C++, only for porting existing code into the Web, as even with the sandbox memory corruptions of data allocated in the linear memory blocks are susceptible to occur.
I don't know if I quite understand this. Is this a web-assembly specific thing, or just the standard C / C++ are "unsafe by default" languages which can cause memory corruption etc because e.g. of off by one errors in pointer arithmetic and so on.
WebAssembly doesn't do bounds checking, besides being in bounds of a linear memory segment.
Basically the access is still in bounds of the allocated memory, but not the cells that one actually wanted to access.
From security point of view, while the WebAssembly module is sandboxes, such corruptions can be triggered from the outside, changing the behaviour of the public API.
We used it to implement a complex, browser-accessible debugger interface for an industrial analyser device. Fast real-time graphs, buttons, menus, etc...
It typically loads in a few seconds in your browser. Works wonders.
We used emscripten + imgui + implot ... All C++ and zero interaction with the low-level WASM itself.
Recommended.
Also emscripten of course, for C/C++.