It's not necessarily about being faster, but about predictability. You're correct in identifying gaming as one use case.

Personally, I am trying to build a basic 2D sim game (think RimWorld) that runs in the browser. I prototyped a demo using TypeScript. React isn't viable because the reconciler isn't intended for handling <canvas /> writes and becomes the perf bottleneck. After that, the GC becomes a bottleneck because of all the allocations.

So, my choices were to either write very special JavaScript that intentionally minimized allocations by pooling objects and favoring mutation over immutability, or choose a better language more suited for the task. JavaScript is absolute garbage if you care about micromanaging performance. You have no idea what you're going to get because V8 optimizations constantly change in subtle ways.

I've since rewritten my approach in Rust + WASM to address those concerns.

It would be nice to be able to have a shared memory buffer that <canvas /> reads from to eliminate the need to call back into JS. I doubt we'll ever get there due to WASM sandboxing, but that has yet to be the limiting factor for me.

FWIW, others smarter than me have come to similar conclusions. https://maxbittker.com/making-sandspiel documents someone creating an app three times: in JS, in Lua, and then in Rust to get it back into the web. They aren't advocating for UI to be written in Rust, but Rust + WASM did solve a need for them, too.

We had (have) that, and the apps were miserable to use for the same reasons enumerated above. The place where it has come closest to succeeding? Video games.

Unfortunately, platforms are too diverse to target as a generic platform without making major sacrifices as to either consistency or usability.

The semantics of the language can be quite complex and it took decades for browsers to agree on them for most use cases. WASM arose out of a failure of browsers to figure out ways to deprecate this—mostly unnecessary—complexity.

> The idea that it needs to be replaced stems from countless failed attempts to shove a bunch of crap into the client with a bunch of frameworks and without a shred of actual engineering discipline.

The same can be said about the implementation of javascript in browsers as well.

We're stuck with it regardless, but our reliance on javascript and its myriad interactions with html and css functions much the same way for large browser vendors as regulatory capture does for large corporations at the state level.