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.

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.

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.

I use it for a web version of some robotics simulation & visualization software I wrote in C++. It normally runs on as an app on Mac or Linux, but compiling to WASM lets me show public interactive demos.

Before WASM, the options were:

- require everyone to install an app to see visualizations

- just show canned videos of visualizations

- write and maintain a parallel Javascript version

Demo at https://throbol.com/sheet/examples/humanoid_walking.tb

> Throbol requires WebGPU. Try with Chrome, Edge, Safari, or Opera.

It's almost there: firefox has shipped it for windows (to begin with): https://mozillagfx.wordpress.com/2025/07/15/shipping-webgpu-...

And safari is coming soon.

So not too long untill it'll be usable.

Doesn't work, neither with Safari nor with Chrome, at least not on macOS Monterey. I guess the whole stack is too modern for my 18-core Intel iMac Pro.

Works fine in Chrome for me.

With access to DOM it could run with no (or just very little) js, no ts-to-js transpiler, no web-framework-of-the-month wobbly frontends perpetually reinventing the wheel. One could use a sane language for the frontend. That would be quite the revolution.

You can just interpolate bits of Javascript inside C++ to access the DOM, like so:

  #include <emscripten.h>

  void sayHello()
  {
    EM_ASM(
      let foo = document.getElementById('foo')
      foo.innerHTML = 'hello';
    );
  }

See https://emscripten.org/docs/porting/connecting_cpp_and_javas...

You already can do that. You need a tiny shim and you can forget it's JS and use all WASM.

Can you point me to a howto/tutorial?

This is wasm-dom for Rust: https://crates.io/crates/wasm-dom There's also web-sys. Those are Rust centric, I'm sure there are others, but basically you only need the whim once, and then you write in your language of choice and compile to WASM, you never have to think about JS. Although... I may question the purist attitude. But you can do it.

Think of it like HTMX, the way people say it "avoids working with JS" (HTMX itself is written in JS). Same principle.

People are already appreciate the accessibility to low level native libraries like duckdb, sqlite, imagemagick, ffmpeg… allowed by wasm. Or high performance games/canvas based applications (figma).

But CRUD developers don’t know/care about those, I guess.