[Ameo]

It 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.

[xipix]

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

[coldtea]

>despite not yet reaching bare-metal levels of performance and energy efficiency.

"Not yet"? It will never reach "bare-metal levels of performance and energy efficiency".

[pjmlp]

Yes there is, WebGPU compute shaders, or misusing WebGL fragment shaders.

[lenkite]

> 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.

[codelikeawolf]

> Do that and frontend web-apps will throw JS into the gutter within a decade.

Why though? What's wrong with JS? I feel like it's gotten a lot better over the years. I don't really understand all the hate.

[ggiigg]

They will not. E.g WordPress and Dajango are 20 years old and still very popular. People don't just jump to hype because hacker news does.

[stkdump]

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?

[lynx97]

> completely abandon the browser rendering path and have everything render into a canvas

Yeah, go ahead and trash the little bit of accessibility we still have. <canvas> by itself already asks webdevs to shit on people with visual disabilities. But getting rid of the DOM (for vague reasons) would really nail the coffin of these pesky blind users. After all, why should they be able to use anything on the internet?

This, and AI making webdevs consider to obfuscate things for scraping reasons, and Microsoft Recall making devs play with the idea of obfuscating OS-level access to their (privacy-sensitive) apps, which in essence would also trash accessibility, are the new nightmares that will haunt me for the next few years.

[yencabulator]

> You also have to have the right high level language to do this kind of DOM interaction and application logic.

That just means you personally like JS. In my opinion many languages are better than it.

[codeflo]

Maybe that's not the dominant mindset anymore, but I for one would love to use a language that's actually built for functional/reactive programming instead of inventing half-baked JavaScript dialects for that purpose. Elm was a language in that spirit, but it never felt complete.

[WorldMaker]

> 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.

[0] https://fsbolero.io/

[Shalomboy]

I found Blazor WASM to be extremely helpful if you have to start from the opposite side of the spectrum. I was working in a self-proclaimed gov agency "Microsoft Shop" whose head of development was adamantly opposed to any sort of JS-driven web app development, but kept accepting requesting apps that fit perfectly into the SPA model. .NET 6 released a few months after I started and with it came a huge amount of progress with Blazor WASM. I had plenty of experience with Vue and Typescript, so Blazor WASM and C# mapped really easily to my existing model of how to build. That similarity also made it easy to onboard new grads who had experience in web dev but weren't familiar with C#. After enough evangelizing, we built a critical mass of projects leveraging Blazor WASM to convince leadership to reconsider his position on Typescript. I can't say enough nice things about the work Steve Sanderson has done to bring Blazor to the public.

[RagnarD]

This misses a hugely important advantage of C# in Blazor WASM (beyond the IMO obvious fact of the huge superiority of C# vs. JS/Typescript) - namely, the ability to use an enormous number of NuGet packages in your browser page. And that covers a very broad range of capability.

[afavour]

> 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.

[catapart]

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.

[pmontra]

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?

[CuriouslyC]

Using WASM lets you bundle native stuff in NPM packages without cross compiling.

[rob74]

> 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.

[gf000]

> DOM (scraping, ad blockers etc.) harder or impossible.

This is a cat mouse fight, and Facebook already does some ultra-shady stuff like rendering a word as a list of randomly ordered divs for each character, and only using CSS to display in a readable way.

But it can't be made impossible, at the worst case we can always just capture the screen and use an AI to recognize ads, wasting a lot of energy. The same is true for cheating in video games and many forms of online integrity problems - I can just hire a good player who would play in my place, and no technology could recognize that.

[ivell]

I suspect this will be coming soon. For ad-driven companies, having an opaque deployment which would prevent ad-blockers would be ideal.

However ads still need to be delivered over the net so there is still some way to block them (without resorting to router/firewall level blocking).

[lynx97]

Add Accessibility to that list. Morally speaking, it is likely more important then scraping and ad-blockers.

[m00dy]

>>possible thanks to the DOM (scraping, ad blockers etc.) harder or impossible.

lol, you can scrape anything visible on your screen.

[p_l]

multiple web apps already work by rendering all to canvas - for example Google Docs and O365

[sebazzz]

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.

[RagnarD]

But why are you? Unless it requires interfacing with a JS library or some JS operation on the DOM, the goal of a Blazor app is to write in C#, not JS. What's your JS code doing that it requires passing C# objects to it? (That said, Blazor supports JS Interop, see https://dev.to/rasheedmozaffar/intro-to-js-interop-in-blazor...)

[shams93]

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.

[gritzko]

That is like Linux on a laptop. When you buy a laptop, you pay for Windows anyway.

[graemep]

Not necessarily. I bought a laptop with Linux preinstalled and its the best thing to do if you buy one with the intent of using Linux on it.

[eek2121]

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.

[cush]

> WASM is designed for situations where performant, low latency compute is needed

I don't get this argument at all. When is performance not needed? Every website can benefit from be faster than it currently is.