Being thread-based, Web Workers are heavyweight (compared to BEAM processes) and data transfer between them isn’t particularly fast (thread hop delay 1- 15ms) - which likely explains the focus on SharedArrayBuffer.
Edit: It seems threads for WebAssembly start web workers without the overhead of 4MB for each V8 isolate for JS and share wasm modules.
Google seems to be working on developing a web standard scheduler/task processor for browsers.
See further:
So I suspect that adapting the BEAM scheduler for the browser environment is a non-trivial port and one has to wonder whether the resulting size of the WebAssembly asset may constrain its usefulness.
You need to implement a fault-tolerant, scalable, soft real-time system with requirements for high availability.
… and while concurrency is an obvious goal on the browser, I don’t think anybody is giving fault tolerant or high availability much thought or value.
For the time being WebAssembly for the browser seems to have a role that is similar to NIFs for the BEAM. So it makes sense that C, C++, and Rust are the officially supported languages, while everything else is considered (highly) experimental.
Making the browser do things, scripting the browser via the various browser APIs, is still the domain of ECMAScript.
- By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this.
(There are future plans to allow WebAssembly to call Web APIs directly).
