WASM is cool, but I don't see any reason to get rid of JS. There's value to having a lingua franca of JIT interpreted code with a standard UI toolkit, and I think those who point out how "insufficient" the DOM is and how "slow" and "unsafe" JavaScript is are simply wrong. They both do their jobs exceedingly well when idiotic and theological ideas are not simply thrown at them by software developers obsessed by convenience over soundness of design.
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.
No, WASM arose out of the work done by Alon Zakai on asm.js at Mozilla which was in good part motivated to show that the web didn't need Google's PNaCl.
That's ancient history. JavaScript has its quirks, but it's not a difficult language to learn or use. Frankly, I don't know where you get this idea that the semantics of the language are hard. In contrast to what? Maybe if you shared some examples I could understand what you're talking about. JavaScript was challenging in decades past not because it was complex but because it was way too simple. Using it on a webpage to do more than very rudimentary things with the browser API meant doing a lot of whacky stuff and using libraries for operations we take for granted today.
> WASM arose out of a failure of browsers to figure out ways to deprecate this—mostly unnecessary—complexity.
As someone else mentioned, no it didn't. WASM came from the same desire as Java applets and browser plugins for Shockwave and Flash, which was to develop applications that run in the browser using entirely different languages and authoring tools.
> The same can be said about the implementation of javascript in browsers as well.
No idea what you are basing this on. Nobody (as in the vast majority) thinks that modern web development is a failure because JavaScript the language is too complex. Everyone is complaining about web development because of all the tools that have been added between the keyboard and the code running in the client, and said tools failing to live up to their promise while encouraging patterns that commonly backfire.
> our reliance on javascript and its myriad interactions with html and css functions
What does that even mean? JavaScript only has as much interaction with the DOM as is demanded of it. If there's a myriad of ways that JavaScript can interact with the DOM, well, that's by design... how else would you have it? CSS functions have nothing to do with JavaScript, if that's what you're actually referring to. At most, JavaScript can listen for some events that are emitted by things like CSS animations.
Of course, I can see how this is mostly irrelevant for some applications like games, but that's still rather niche compared to, you know, useful and wide-spread apps that people actually want to use.
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.
Many people would argue that the native iOS and Android UI toolkits beat HTML/css.
6dc610bc2d7c1ba9b6783c61bf8c79897c733964e845d574990b120954428d69
ae0f36b12c0a363dd4eaf94fb65b33bd7c7f55e879a85c24394d6d06d02af4d5
From https://webassembly.org/docs/faq/#is-webassembly-trying-to-r...
> HTML/CSS/JavaScript UI around a main WASM-controlled center canvas, allowing developers to build accessible experiences
I can easily see that being abused obviously. (If anyone has any useful articles regarding accessibility and WASM please share)
And closed for humans? I am lucky enough that I haven’t yet met an unblockable canvas ad, but they are coming. You also won’t get any support from the browser, no text select, no right click, no accessibility whatsoever, no reader mode, probably not even have proper mobile support, because it just happened to react to clicks, and not touches..
Unless it is some specific simulation/game/ultra-complex gui (think photoshop), I explicitly don’t want to see any canvas rendering, even though I really dislike JS as a language/platform.
Where are our cloud-based DAWs? Where's CAD?
There's a lot of OS-based tooling that never made the leap to web-based because of how limiting the web environment is and WASM is a great step towards solving that.
Additionally, the sandboxing is suuuuper useful in today's world. Docker either wouldn't exist, or wouldn't have the clout it has today, if WASM had been fully fleshed out when Docker took off (https://thenewstack.io/when-webassembly-replaces-docker/)
Also, it's nice being able to opt-out of garbage collection by compiling a non-GC'ed language to WASM. Latency-sensitive applications (real-time gaming) don't want to aggressively manage object lifetimes in JavaScript. Like, yeah, you could, in theory, avoid excessively allocating strings and strongly prefer mutating existing objects vs immutability, but those decisions lead to more fragile code and ultimately limit the depth/quality of tooling you can create.
Tinker CAD feels great and it is built with JS/HTML with the 3D view done in WebGL/Canvas: https://www.tinkercad.com/
I could maybe see it for gaming at some point, but it is a long way to go. All screen drawing (canvas, DOM manipulation, etc) are still going through JavaScript. So none of that is any faster.
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.
CAD is already taken for.
https://www.infoq.com/presentations/autocad-webassembly/
> if WASM had been fully fleshed out when Docker took off
It was already there, as Java and .NET application servers, which Kubernetes + WASM containers are now re-inventing as something "revolutionary", now with YAML spaghetti instead of XML config files.