I use multi-threading extensively in JavaScript (it's part of my day job). I can tell you that you have to _really really_ want it and it is very hard to use it to improve performance.
Serialization/deserialization overhead is non-trivial while shared primitives like SharedArrayBuffer are mostly useless and disabled without prohibitivly restrictive security headers.
To get anything useful out of JavaScript threading, you need to implement hydration and synchronization mechanisms which are slow and unbelievably complex.
Meanwhile, multithreading is effortless and performant in Rust or Go.
If my backend is in Rust already, I could simply reuse my API types/structs.
I could use language specific serialization formats for REST endpoints (like Rust's bincode) rather than JSON or protobuf - which is faster to parse and compresses better.
If the web opens up more maybe we could gain access to raw TCP/UDP sockets and have access to highly efficient streaming from our servers - enabling use cases like usable game netcode (which is currently impossible). This benefits other realtime application use-cases too, like finance applications, chat applications and streaming services.
Don't forget the memory footprint of web applications. Imagine if the browser figured out there was no JavaScript running and it didn't spawn a JS runtime - imagine a tab consuming 15mb of RAM rather than 250mb.
...
I'm not saying JavaScript is bad and that we don't need it to evolve - I'm just saying that the ROI on a fully featured wasm runtime in the browser is massive and that browser vendors & the standards committee are sleeping on it - which is hugely frustrating.
Serialization/deserialization overhead is non-trivial while shared primitives like SharedArrayBuffer are mostly useless and disabled without prohibitivly restrictive security headers.
To get anything useful out of JavaScript threading, you need to implement hydration and synchronization mechanisms which are slow and unbelievably complex.
Meanwhile, multithreading is effortless and performant in Rust or Go.
If my backend is in Rust already, I could simply reuse my API types/structs.
I could use language specific serialization formats for REST endpoints (like Rust's bincode) rather than JSON or protobuf - which is faster to parse and compresses better.
If the web opens up more maybe we could gain access to raw TCP/UDP sockets and have access to highly efficient streaming from our servers - enabling use cases like usable game netcode (which is currently impossible). This benefits other realtime application use-cases too, like finance applications, chat applications and streaming services.
Don't forget the memory footprint of web applications. Imagine if the browser figured out there was no JavaScript running and it didn't spawn a JS runtime - imagine a tab consuming 15mb of RAM rather than 250mb.
...
I'm not saying JavaScript is bad and that we don't need it to evolve - I'm just saying that the ROI on a fully featured wasm runtime in the browser is massive and that browser vendors & the standards committee are sleeping on it - which is hugely frustrating.