alt Hacker NewsIt seems to me that Wasm largely succeeded and meets most/all of the goals for when it was created. The article backs this up by listing the many niches in which its found support, and I personally have deployed dozens of projects (both personal and professional) that use Wasm as a core component.
I''m personally a big fan of Wasm; it has been one of my favorite technologies ever since the first time I called malloc from the JS console when experimenting with an early version of Emscripten. Modern JS engines can be almost miraculously fast, but Wasm still offers the best performance and much higher levels of control over what's actually running on the CPU. I've written about this in the past.
The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps. In this regard, I'd have to agree. It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental.
I've tried out some of the Wasm-powered web frameworks like Yew and not found them to provide an improvement for me at all. It just feels like an awkwardly bolted-on layer on top of JS and CSS without adding any new patterns or capabilities. Like you still have to keep all of the underlying semantics of the way JS events work, you still have to keep the whole DOM and HTML element system, and you also have to deal with all the new stuff the framework introduces on top of that.
Things may be different with other frameworks like Blazor which I've not tried, but I just find myself wanting to write JS instead. I openly admit that it might just be my deep experience and comfort building web apps using React or Svelte though.
Anyway, I strongly feel that Wasm is a successful technology. It's probably in a lot more places than you think, silently doing its job behind the scenes. That, to me, is a hallmark of success for something like Wasm.
Replies
> It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental.
No, it is NOT "something else or more fundamental" - it is most certainly the lack of proper, performant access to the DOM without having to use crazy, slow hacks. Do that and frontend web-apps will throw JS into the gutter within a decade.
> Things may be different with other frameworks like Blazor which I've not tried, but I just find myself wanting to write JS instead.
Blazor WASM probably is among the best approaches to what is possible with WASM today, for better and worse. C# is a great language to write domain code in. A lot of companies like C# for their backends so you get same-language sharing between backend and frontend. The Razor syntax is among the better somewhat type-safe template languages in the wild, with reasonably good IDE support. C# was designed with FFI in mind (as compared to Java and some other languages) so JS imports and exports fit reasonably well in C#; the boundaries aren't too hairy.
That said, C# by itself isn't always that big of leap from Typescript. C# has better pattern matching today, but overall the languages feel like step-brothers and in general the overhead of shipping an entire .NET CLR, most of the BCL, and your C# code as web assembly is a lot more than just writing things more vanilla in Typescript. You can also push C# more functional with libraries like LanguageExt (though you also fight the reasons to pick C# by doing so as so many engineers don't think LanguageExt feels enough like C# to justify using C#).
I'm curious to try Bolero [0] as F# would be a more interesting jump/reason for WASM, but I don't think I could sell it to engineering teams at my day job. (Especially as it can't use Razor syntax, because Razor is pretty deeply tied to C# syntax, and has its own very different template languages.)
With WASM not having easy direct access to the DOM, Blazor's renderer is basically what you would expect it to be: it tosses simple objects over to a tiny Virtual DOM renderer on the JS side. It has most of the advantages and disadvantages of just using something like React or Preact directly, but obviously a smaller body of existing performance optimizations. Blazor's Virtual DOM has relatively great performance given the WASM to JS and back data management and overhead concerns, but it's still not going to out-compete hand written Vanilla JS any time soon.
I never thought that it would be a promising approach to build entire web apps using wasm. You don't just have to make it possible to interact with the DOM. You also have to have the right high level language to do this kind of DOM interaction and application logic. JS isn't bad for that purpose and it would probably take a lot to find something that is much better (which compiles to WASM instead of js, like ts and svelte do).
The only real avenue for js-free web applications would be to completely abandon the browser rendering path and have everything render into a canvas. There are experiments to use UI toolkits designed for the desktop. But even that I see more of a niche solution and unlikely to become very widely used. HTML/css/js have become the lingua franca of UI development and they are taking over desktop applications as well. Why should that trend reverse?
At work we’re incrementally rewriting a legacy Javascript Electron application in Blazor / C# WASM. The biggest issue we’ve run into as far as WASM interop goes is that it is not really possible to pass objects between WASM and JS. It requires some form of serialization to JSON or a different blittable format. Since the data we work with in the application is quite large, this has caused some headaches.
> The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps.
Agreed and I’m personally glad progress on that hasn’t moved quickly. My biggest fear with WASM is that even the simplest web site would end up needing to download a multi MB Python runtime just because the author didn’t want to use JS!
The sad reality is that the slowness very often comes from the DOM, not from JavaScript. Don’t get me wrong, there could be improvements, e.g. VDOM diffing would be a cinch with tuples and records, but ultimately you have to interact with the DOM at some point.
Agreed. This article feels like someone asking "What happened to ffmpeg?"
It's like...ah, yeah, I see how you might not hear about it, but uh... it's everywhere.
About building web apps:
> It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental.
More fundamentally, every front end developer uses more or less the same JS language (Typescript included) and every module is more or less interoperable. As WASM is a compilation target, every developer could be using a different language and different tools and libraries. One of them could have reached critical mass but there is a huge incumbent (JS) that shadows everything else. So special purpose parts of web apps can be written in one of those other languages but there still is a JS front end between them and the user and GUIs can be huge apps. It looks like a system targeted to optimizations.
And for the backend, if one writes Rust or any other compiled language that can target WASM, why compiling to WASM and not to native code?
> The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps.
I for one hope that doesn't happen anytime soon. YouTube or Spotify could theoretically switch to Wasm drawing to a canvas right now (with a lot of development effort), but that would make the things that are currently possible thanks to the DOM (scraping, ad blockers etc.) harder or impossible.
X used yew and rust to rebuild their client and had success in that they are dealing with lots of heavy lifting where these tools start to show their value for large scale products.
For most products its immense overkill, for a lot of stuff even react is total overkill where htmx is a better choice.
It won't ever replace anything, because most folks don't understand the tech. I've no other way to explain this except to present this question: which is more popular, ASM, or literally any other higher level language (C, C++, etc.)?
Compilers, languages, and frameworks were built for ease of use for the end developer specifically so that any type of ASM would be avoided. Web technologies/frameworks along with Operating system APIs, etc. were a FURTHER level of abstraction. WASM has it's place, just the same as ASM has it's place. Trying to replace React with x86 ASM sounds foolish, does it not? The same goes for WASM. Why?
WASM is designed for situations where performant, low latency compute is needed, along with low level control, etc. Even IF they integrated DOM, very few would use it. Most of today's developers don't even know ASM for any platform, and they aren't about to learn it. They want to be productive, not rewrite basic stuff.
I mean shoot, as much as I dislike the AI bubble (AI/LLMs are great, corporate america is the issue), it is SHOWING what people want, which most of us already knew people wanted: we want to automate out the boring stuff and focus on the hard stuff.
That is like Linux on a laptop. When you buy a laptop, you pay for Windows anyway.
The article seems to evaluate Wasm as it were a framework upon which apps are built. It's not that, it's an orthogonal technology allowing CPU optimisations and reuse of native code in the browser. Against that expectation, it has been a huge success despite not yet reaching bare-metal levels of performance and energy efficiency.
One such example: audio time stretch in the browser based upon a C++ library [1]. There is no way that if this were implemented in JS that it could deliver (a) similar performance or (b) source code portability to native apps.
[1] https://bungee.parabolaresearch.com/change-audio-speed-pitch