[apatheticonion]

High performance web-based applications is pretty high on my list.

Low memory usage and low CPU demand may not be a requirement for all websites because most are simple, but there are plenty of cases where JavaScript/TypeScript is objectively the wrong language to be using.

Banking apps, social network sites, chat apps, spreadsheets, word processors, image processors, jira, youtube, etc

Something as simple as multithreading is enough to take an experience from "treading water" to "runs flawlessly on an 8 year old mobile device". Accurate data types are also very valuable for finance applications.

Another use case is sharing types between the front and back end.

[3cats-in-a-coat]

But... we already have all that.

Multithreading could've been a bit more convenient, but if you want it, you can get it. Don't tell me those revolutionaries that want to revolutionize the web give up so easily.

[apatheticonion]

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.