I think one the big things with web assembly is it's shear potential is huge.
In theory, WASM could be a single cross platform compile target, which is kind of a CS holy grail. It's easy to let your mind spin up a world where everything is web assembly, a desktop enivornment, a server, day to day software applications.
After I've imagined all of that, being told web assembly helps some parts of Figma run faster feels like a big let down. Of course that isn't fair, almost nothing could live up to the expectations we have for WASM.
Its development is also by committee, which is maybe the best option for our current landscape, but isn't famous for getting things going quickly.
> On every WebAssembly discussion, there is inevitably one comment (often near the top) asking what happened
The meat of the article is informative, but the headline and motivation is based on this statement. It’s doesn’t reflect my experience but maybe I just don’t hang out in the same internet spots as the OP.
> We don’t yet see major websites entirely built with webassembly-based frameworks
I don’t know why this entered into the zeitgeist. I don’t think this was ever a stated goal of the WebAssembly project. I get the sense that some people assumed it and then keep wondering why this non-goal hasn’t been realized.
I'm actually using WASM (from Rust) on a image editor project. It's pretty good - I see around a 4x perf improvement over JS depending on the benchmark.
But what happened? Why am I not using it for all of my other random side projects? I posit that the JS ecosystem got so incredibly good that it it's a no-brainer for a very large percentage of workflows. React + Vite + TypeScript is an incredibly productive stack. I can use it to build all but the most demanding apps productively. Additionally, JS is pretty fast these days, so the speed boost from WASM isn't actually that meaningful for most use cases. Only really heavy use cases like media editing or Figma-like apps really benefit from what WASM has to offer.
A big thing overlooked with speed is binary size. WebAssembly is incredibly inefficient at storage space. For people still on DSL they will have to wait seconds (or minutes in the case of Godot) for the blob to download before execution can start.
Meanwhile javascript will be much faster to download since it is smaller and javascript can execute while it is downloading.
It's an incredibly powerful tool, but very much a power-user one. Expecting your average front-end logic to be compiled in WebAssembly does not make much sense.
The data exchange between host and guest is still unspecified. You can not access host objects from Wasm. Most do just string serialization, which is not fast. Or they write libraries for some particular languages, which damages the universal idea of Wasm. And WASI seems to be quite controversial: https://www.assemblyscript.org/standards-objections.html
I am kind of disappointed with regard to WebAssembly.
There were several articles that promoted it heavily - aka the hype phase.
And then ... nothing really materialized. If you look at, for instance, ruby WASM, https://github.com/ruby/ruby.wasm - there is virtually zero real documentation. Granted, this is a specific problem of ruby, and japanese devs not understanding english; but when you search for webassembly, contrast it to the numerous tutorials we have with regards to HTML, CSS, JavaScript. I get it, it is younger, it is harder than the other three tech stacks, but virtually nothing really improves here. It is like a borne-dead technology that has only a tiny niche, e. g. Rust developers. That's about it. And I fear this is also not going to change anymore. After a while, if the hype fails to deliver, people will lose interest - and a technology will eventually subside. That also happened to e. g. XHTML and the heavy use of XML in general in, say, 2000. I also don't think WebAssembly can be brought back now that the hype stage went off.
Many of the build tools Javascript people use are written in Rust now. Some of them can be made to run in browsers, via WASM. React, the defacto UI framework for Javascript has a lot of web assembly components. A lot of the npm ecosystem has quietly brought in web assembly. And a lot of UI stuff gets packaged up as web components these days; some of that uses WASM as well.
If you pulled the plug on WASM, a lot would stop working and it would heavily impact much of the JS frontend world.
What hasn't caught on is modern UI frameworks that are native wasm. We have plenty of old ones that can be made to work via WASM but it's not the same thing. They are desktop UI toolkits running in a browser. The web is still stuck with CSS and DOM trees. And that's one of the areas where WASM is still a bit weak because it requires interfacing with the browser APIs via javascript. This is a fixable problem. But for now that's relatively slow and not very optimal.
Solutions are coming. But that's not going to happen overnight. But web frontend teams being able to substitute Javascript for something else is going to require more work. Mobile frontend developers cross compiling to web is becoming a thing though. Jetbrain's compose multiplatform is has native Android/IOS supported now with a canvas rendered web frontend supported in Beta currently.
You can actually drive the dom from WASM. There are some RUST frameworks. I've dabbled with using kotlin's wasm support to talk to browser dom APIs. It's not that hard. It's just that Rust is maybe not ideal (too low level/hard) for frontend work and a lot of languages lack frameworks that target low level browser APIs. That's going to take years to fix. But a lot compiles to wasm at this point. And you kind of have access to most of the browser APIs when you do. Even if there is a little performance penalty.
The folks behind WASM are wilfully blind to the big honking use case that everyone wants (a fully-featured JS replacement, targetable in any language), in favour of an abstract adventure in chasing some ideal Platonic ISA, except there's no obvious market or practical use case for such a thing.
WASM will live and die in the browser. I wish the folks behind it would acknowledge that fact and give it sufficient browser interop to finally render JS unnecessary.
Feels like most of the disappointment comes from the wrong expectation. Wasm was never going to replace HTML/CSS/JS for normal frontend work, and JS got good enough that most apps don’t need it anyway. On the other hand, Wasm as a universal runtime (WASI replacing containers, etc.) is clearly still unfinished.
Where it has worked is as infrastructure: fast, sandboxed, portable code for the parts that actually need it. A lot of people are already using it indirectly without realizing. So it’s less "what happened to Wasm?" and more "it didn’t become the silver bullet people imagined."
We love wasm! You can get pretty far with it. We’re building new machine learning experiment tracker using wasm on the front end. (If you know what Wandb or Neptune is, you should give us a try!)
As far as I know, we are the fastest on the market. The multithreaded support is a pain though.
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.
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.
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.
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 weakest point in any computer system is the bag of meat operating the thing; the second weakest point is the network. Most web apps that are slow are slow because of the endless chit-chat between client and server across the network, and because too much business logic runs on the client machine, which might be a ten-year-old smartphone. For these apps, improving performance is about minimising the number of HTTP request-response pairs and moving logic to the server, not making the frontend code run faster.
> I figure most are under the impression that the advancement of this technology would have had a more visible impact on their work. That they would intentionally reach for and use Wasm tools.
> Many seem to think there is a path to Wasm replacing JavaScript within the browser—that they might not need to include a .js file at all. This is very unlikely.
This is because most of us are not writing fancy browser-based 3D game engines; we're writing boring enterprisey CRUD apps, and the only things we want from out frontend code are HTTP request-response handling and DOM manipulation. Consequently, the irrelevance of WASM evangelism is frankly boorish.
WASM works. Except for all the convoluted edge cases where it doesn’t.
Also, wasm doesn’t solve enough real problems. JavaScript sucks but is plenty good enough for most things. Wasm unlocks a few things. But it makes no sense for, say, Steam games that are tens of gigabytes.
If wasm didn’t exist the internet and world would be… fine? Use JavaScript in a browser or go actual native. The space inbetween for wasm exists but is extremely small. Especially for anything other than cool visualization widgets.
"We don’t yet see major websites entirely built with webassembly-based frameworks."
The more telling question to me is:
Do we see real world websites that are not just tech demos coming out of WASM aficionados circles. Sites that are actually useful to a significant number of people, even if we wouldn't necessarily call them major websites.
From my experience, WASM is great for easily porting existing codebases to the browser. It took me less than a day to download Emscripten, learn a little about WASM, make one toy project, and then port a 20-year-old, 40-KLOC C++ project to the browser [1]. The last part only took me half an hour, and I don't even write C++.
Anyone knows why docker is dropping wasm workloads? I never heard of anyone using it, I thought it was because wasi hasn't reached "1.0" yet, so ecosystem is still small.
Wasm and wasi are very promising, as stated in the article, it's safe/isolated by default, it can target different hardware and almost any popular language (in theory) can be compiled to wasm. It sounds perfect on paper. It's quick to start (quicker than docker). Maybe it will be replacement/supplement for lambda-esque type of workloads.
>It is almost 1:1 in that you can compile WAT to Wasm and then back to WAT with barely any loss in information (you may lose variable names and some metadata).
I love it! It reads like, "you can put your snowman in a oven to obtain water and then the water to a snow machine to get to your initial material state with almost no information lost."
One thing that happened to WebAssembly is that it allowed for npm packages like PGlite to be created. With a simple `npm install` you now have a PostgreSQL instance in your web or node app, no (connection) strings attached (pun intended). Full disclosure: I am one of the maintainers.
WASM for frontend, at least, has been held back by fundamental tools like bundle splitting, hot-reload, debugger symbols, asset integration, etc. We spent a lot of 2025 working on improving this. Vite and friends are really good!
I've been working on a big Dioxus project recently and am pretty happy with where WASM is now. The AI tools make working with Rust code much faster. I'm hopeful people gravitate towards WASM frameworks more now that the tools are better.
74 comments
[ 3.5 ms ] story [ 65.3 ms ] threadIn theory, WASM could be a single cross platform compile target, which is kind of a CS holy grail. It's easy to let your mind spin up a world where everything is web assembly, a desktop enivornment, a server, day to day software applications.
After I've imagined all of that, being told web assembly helps some parts of Figma run faster feels like a big let down. Of course that isn't fair, almost nothing could live up to the expectations we have for WASM.
Its development is also by committee, which is maybe the best option for our current landscape, but isn't famous for getting things going quickly.
The meat of the article is informative, but the headline and motivation is based on this statement. It’s doesn’t reflect my experience but maybe I just don’t hang out in the same internet spots as the OP.
> We don’t yet see major websites entirely built with webassembly-based frameworks
I don’t know why this entered into the zeitgeist. I don’t think this was ever a stated goal of the WebAssembly project. I get the sense that some people assumed it and then keep wondering why this non-goal hasn’t been realized.
But what happened? Why am I not using it for all of my other random side projects? I posit that the JS ecosystem got so incredibly good that it it's a no-brainer for a very large percentage of workflows. React + Vite + TypeScript is an incredibly productive stack. I can use it to build all but the most demanding apps productively. Additionally, JS is pretty fast these days, so the speed boost from WASM isn't actually that meaningful for most use cases. Only really heavy use cases like media editing or Figma-like apps really benefit from what WASM has to offer.
Meanwhile javascript will be much faster to download since it is smaller and javascript can execute while it is downloading.
WebAssembly makes it possible to:
* Run x86 binaries in the browser via JIT-ting (https://webvm.io)
* Run Java applications in the browser, including Minecraft (https://browsercraft.cheerpj.com)
* Run node.js containers in the browser (https://browserpod.io)
It's an incredibly powerful tool, but very much a power-user one. Expecting your average front-end logic to be compiled in WebAssembly does not make much sense.
From my understanding WASI never was expected to run a browser. I'd rather listen complains about WIT being very rust-biased.
Also seems to be okay with having a shim in wasm module to adapt to browser behavior, but not the other way around?
There were several articles that promoted it heavily - aka the hype phase.
And then ... nothing really materialized. If you look at, for instance, ruby WASM, https://github.com/ruby/ruby.wasm - there is virtually zero real documentation. Granted, this is a specific problem of ruby, and japanese devs not understanding english; but when you search for webassembly, contrast it to the numerous tutorials we have with regards to HTML, CSS, JavaScript. I get it, it is younger, it is harder than the other three tech stacks, but virtually nothing really improves here. It is like a borne-dead technology that has only a tiny niche, e. g. Rust developers. That's about it. And I fear this is also not going to change anymore. After a while, if the hype fails to deliver, people will lose interest - and a technology will eventually subside. That also happened to e. g. XHTML and the heavy use of XML in general in, say, 2000. I also don't think WebAssembly can be brought back now that the hype stage went off.
If you pulled the plug on WASM, a lot would stop working and it would heavily impact much of the JS frontend world.
What hasn't caught on is modern UI frameworks that are native wasm. We have plenty of old ones that can be made to work via WASM but it's not the same thing. They are desktop UI toolkits running in a browser. The web is still stuck with CSS and DOM trees. And that's one of the areas where WASM is still a bit weak because it requires interfacing with the browser APIs via javascript. This is a fixable problem. But for now that's relatively slow and not very optimal.
Solutions are coming. But that's not going to happen overnight. But web frontend teams being able to substitute Javascript for something else is going to require more work. Mobile frontend developers cross compiling to web is becoming a thing though. Jetbrain's compose multiplatform is has native Android/IOS supported now with a canvas rendered web frontend supported in Beta currently.
You can actually drive the dom from WASM. There are some RUST frameworks. I've dabbled with using kotlin's wasm support to talk to browser dom APIs. It's not that hard. It's just that Rust is maybe not ideal (too low level/hard) for frontend work and a lot of languages lack frameworks that target low level browser APIs. That's going to take years to fix. But a lot compiles to wasm at this point. And you kind of have access to most of the browser APIs when you do. Even if there is a little performance penalty.
Which almost no-one cares about.
WASM will live and die in the browser. I wish the folks behind it would acknowledge that fact and give it sufficient browser interop to finally render JS unnecessary.
Where it has worked is as infrastructure: fast, sandboxed, portable code for the parts that actually need it. A lot of people are already using it indirectly without realizing. So it’s less "what happened to Wasm?" and more "it didn’t become the silver bullet people imagined."
As far as I know, we are the fastest on the market. The multithreaded support is a pain though.
https://minfx.ai
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.
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.
For most products its immense overkill, for a lot of stuff even react is total overkill where htmx is a better choice.
> I figure most are under the impression that the advancement of this technology would have had a more visible impact on their work. That they would intentionally reach for and use Wasm tools.
> Many seem to think there is a path to Wasm replacing JavaScript within the browser—that they might not need to include a .js file at all. This is very unlikely.
This is because most of us are not writing fancy browser-based 3D game engines; we're writing boring enterprisey CRUD apps, and the only things we want from out frontend code are HTTP request-response handling and DOM manipulation. Consequently, the irrelevance of WASM evangelism is frankly boorish.
Also, wasm doesn’t solve enough real problems. JavaScript sucks but is plenty good enough for most things. Wasm unlocks a few things. But it makes no sense for, say, Steam games that are tens of gigabytes.
If wasm didn’t exist the internet and world would be… fine? Use JavaScript in a browser or go actual native. The space inbetween for wasm exists but is extremely small. Especially for anything other than cool visualization widgets.
The more telling question to me is:
Do we see real world websites that are not just tech demos coming out of WASM aficionados circles. Sites that are actually useful to a significant number of people, even if we wouldn't necessarily call them major websites.
https://cbva.com/
comes to my mind, but there must be more.
Instead of building a true portable binary format with system access, we got a JavaScript VM from TEMU:
- Reference Types
- Exception Handling
- GC
Makes GC'd languages compile better, not system programming
Meanwhile, the actually needed capabilities remain blocked forever:
- Memory: Still can't mmap, still can't allocate outside linear memory
- Networking: Still needs JS interop bullshit
- Device: Still need JS interop bullshit and still sandboxed behind browser security model
The Result: WASM isn't a serious systems target, it's a compilation artifact for managed languages that could've just targeted JS directly
[1] https://poincare.matf.bg.ac.rs/~janicic/gclc/
Wasm and wasi are very promising, as stated in the article, it's safe/isolated by default, it can target different hardware and almost any popular language (in theory) can be compiled to wasm. It sounds perfect on paper. It's quick to start (quicker than docker). Maybe it will be replacement/supplement for lambda-esque type of workloads.
https://docs.docker.com/desktop/features/wasm/
I love it! It reads like, "you can put your snowman in a oven to obtain water and then the water to a snow machine to get to your initial material state with almost no information lost."
WASM for frontend, at least, has been held back by fundamental tools like bundle splitting, hot-reload, debugger symbols, asset integration, etc. We spent a lot of 2025 working on improving this. Vite and friends are really good!
I've been working on a big Dioxus project recently and am pretty happy with where WASM is now. The AI tools make working with Rust code much faster. I'm hopeful people gravitate towards WASM frameworks more now that the tools are better.