alt Hacker NewsWhat happened to WebAssembly
Comments
As someone who worked actively with webassembly for the last few years, and is about to drop a WASM based framework, here's what happened:
- The ecosystem evolved fast, then slow. This caused adoption problems, especially for things such as WASI and Component model, as a lot of folks did it their own way/using 3rd party, which now meant they had to rewrite to this new thing that still isn't fully properly supported everywhere.
- The way it's "developed" means a lot of things are distributed, unsynced and have different support levels based on the engine you're using. This causes confusion among developers, especially since you have to go from reading an article, to reading a spec, to reading a github issue, then you're 3 repositories deep reading random rust code at 2 AM trying to figure out if you can rely on this stranger's fork just to try something out that should have been dead simple.
- Both of these combined can lead to even greater confusion for our LLM's, as they are trained on varied data which is by now stale, so they can often misunderstand things or look for things that aren't there anymore, just like us humans would.
- And now let's focus on the biggest and most important one IMO: Javascript/Typescript support. That is the holy grail for any technology that wants to be a widely adopted intermediary. While it is possible, you are layering hacks on hacks and begging that the next user won't break it all. Until my users can bring whatever they're using with them, the transition isn't really worth it, and writing my own wiring for every possible combination/need is quite unnecessary. We got a step closer with Web Containers, but by that time a lot of folks already moved onto Bun.
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.
Tooling is holding back WebAssembly.
It is very hard to debug WebAssembly applications, depending on the source language, we are still on printf debugging kind of experience.
Even the DWARF plugin for Chrome (only, nowhere else), hasn't been updated since 2023.
Then there is the whole experience, again depending on the language, to produce a .wasm file, alongside the set of imports/exports for the functions, instead of a plain "-arch=wasm".
GC support is now available, however it is a "yes but", because it doesn't support all kinds of GC requirements, thus some ecosystems like .NET, still need to ship their own.
Finally we have WIT trying to be yet another go at COM/CORBA/gRPC.
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.
We use WebAssembly aggressively at Leaning Technologies across our tools.
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.
I work on Dioxus (Rust WASM framework).
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.
I've worked with WebAssembly on several real world use cases
Codec support: Built video and audio decoding in Wasm to bring codec support to browsers that didn't have it natively. Also helped with a custom video player to work around HLS latency issues on Safari.
Code sharing: We had business logic written in C that needed to run both frontend and backend. Compiled it to Wasm for the frontend, which guaranteed identical behaviour across environments.
Obfuscation: Currently exploring Wasm for "hiding" some JavaScript logic by rewriting critical parts in Rust and compiling to Wasm. We tried JS obfuscators (including paid ones), but they killed performance. Wasm gives us both obfuscation and better performance.
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.
> 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.
Here is a minimal example for inline webassembly: A function a that adds two numbers. Can someone make the entire example shorter? (added linebreaks for readability)
<!DOCTYPE html>
<p id=r>
<script>
WebAssembly.instantiateStreaming(fetch(
'data:application/wasm;base64,AGFzbQEAAAABBwFgAn9/AX8DAgEABwUBAWEAAAoJAQcAIAAgAWoL'))
.then(x=>r.append(x.instance.exports.a(51,4)))
</script>
(module
(func (export "a") (param i32 i32) (result i32)
local.get 0
local.get 1
i32.add))I've written about limitations of WebAssembly https://qouteall.fun/qouteall-blog/2025/WebAsembly%20Limitat...
WebAssembly still doesn't provide a way to release memory back to browser (unless using Wasm GC). The linear memory can only grow.
The Wasm GC limits memory layout and doesn't yet support multi-threading.
Wasm multithreading has many limitations. Such as cannot block on main thread, cannot share function table, etc. And web worker has "impedance mismatch" between native threads.
And tooling is also immature (debugging requires print debugging)
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++.
Something I wonder is, what happened to asm.js? It got killed by WASM. In a way this is good, WASM is a "better" solution, being a formal bytecode machine description, but on the other hand, asm.js would not have the same limitations e.g. with respect to DOM interaction, or debates on how to integrate garbage collection, since you stay squarely in the JS VM you get these things for free.
Basically in some ways it was a superior idea: benefit from the optimizations we are already doing for JS, but define a subset that is a good compilation target and for which we know the JS VM already performs pretty optimally. So apart from defining the subset there is no extra work to do. On the other hand I'm sure there are JS limitations that you inherit. And probably your "binaries" are a bit larger than WASM. (But, I would guess, highly compressible.)
I guess the good news is that you can still use this approach. Just that no one does, because WASM stole the thunder. Again, not sure if this is a good or bad thing, but interesting to think about... for instance, whether we could have gotten to the current state much faster by just fully adopting asm.js instead of diverting resources into a new runtime.
WebAssembly was supposed to be the first “universal runtime” that could literally run anywhere at lightning speed, and while it was certainly an impressive achievement, it was clear to me that the technology friction was mostly on how it was integrated, or more specifically how it was integrated with tools, debugging, interoperation, etc. ~
The web technologies and frameworks that we have today and how we use them to create solutions, still a lot of developers rely on JavaScript. It may be an outdated language with a lot of issues and problems, but it is still the most popular programming language today. Platforms tend to fail because the workflow surrounding them doesn't offer the flexibility to make the most of the platform.
The most valuable lesson to learn is that potential alone doesn't drive widespread use of a technology. The flexible integration offered by JavaScript is the only thing that made widespread use of it possible. What is the most valuable thing that Web Assembly offered you? What is the missing element in Web Assembly that makes it hard to use? What does the new technology offer that makes it harder to use and does it repeat the same patterns as Web Assembly?
WebAssembly in the browser does feel great when you look at things like Pyodide/Pyolite, JupyterLite, xeus, webR and even small tools like texlyre – you get a full language/runtime locally with zero server, just WASM and some JS glue. The sad part is that VS Code for the Web never really became that kind of self-contained WASM IDE: the WASI story is focused on extensions and special cases, and running real toolchains (Emscripten, full Python, etc.) keeps breaking or depending on opaque backend magic. So right now the best “pure browser” experiences are these focused notebook/tool stacks, not the general-purpose web IDE people were hoping vscode.dev would become.
Technical details only verify Wasm's potential. Wide adoption is not a technical matter.
Just like with JVM and other better options before and after it, it's politics, interests and momentum. JVM in the browser was not killed by technology, it was killed by Microsoft. Similarly, we should look who gains and loses relative to other if Wasm becomes mainstream.
Easy portability and less platform dependence. Who wants it, who does not? Apple, Microsoft, Google, ...
Just like with JVM the Wasm can be killed with wrong embrace. Microsoft Java Virtual Machine (MSJVM) was named in the United States v. Microsoft Corp. antitrust civil actions, as an implementation of Microsoft's "Embrace, extend and extinguish" strategy. Adopt JVM, remove portability with extensions.
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.
> There is a lot of desire for advancement, but standardization means decisions are hard to reverse. For many, things are moving too quickly and in the wrong direction.
Most Wasm proposals are very elegantly designed and effective - meaning they provide lots of value for relatively minor specification bloat. Examples are tail-calls, multi-value, custom-page-sizes, memory64 and even gc.
However, the simd and flexible-simd increased spec bloat by a lot, are not future-proof and caused more fragmentation due to non-determinism. In my opinion work should have focused on flexible-vector (SVE-like) which was more aligned to Wasm's original goals of near-native performance. The reason for this development was that simd was simpler to implement and thus users could reap benefits earlier. Unfortunately, it seems the existence of simd completely stalled development of the superior flexible-vectors proposal.
If flexible-vectors (or similar) will ever be stabilized eventually, we will end up in one of two (bad) scenarios:
1) People will have to decide between simd and flexible-vectors for their compilation, depending on their target hardware which is totally against Wasm's original goals.
2) The simd proposal will be mostly unused and deprecated. Dead weight.
For me the biggest issue is all the articles and videos showing how people run entire companies in WASM and then sample code with fn(i32, i32) i32. The interoperability between languages and pre-defined APIs like WASI are just not there yet and its just rough to use.
Of course crazy things can be (were already!) done with WASM, but it's more like Rust in the beginning and is still advertised as Go ;)
To add to the author's list of examples, the regex test site Regex 101 (http://regex101.com/) relies on WebAssembly. To verify this in Firefox, you can set javascript.options.wasm to false, and you will be instructed to use a browser supporting WebAssembly.
If you're willing to risk some safety guarantees, then you can embed SQLite in Go without cgo by using WASM builds of SQLite. In particular, this package: https://github.com/ncruces/go-sqlite3
Note: the risk here is that it's unclear how well-tested SQLite WASM builds are compared to native builds for things like data integrity. With that said, in most of my personal projects using Go, I frequently reach for the WASM builds because it keeps builds fast and easy.
Also, I want to mention that I have seen web apps that are C# / Blazor programs compiled into WebAssembly. The accessibility is predictably terrible, but I have seen at least one such web app in the wild. I assume this is largely why one doesn't encounter WASM web frameworks often. In any case, WASM is surprisingly useful in many niches, and that's kind of the problem for WASM's visibility: the niches where I find WASM useful are almost completely disjoint from each other. But it's a solid technology nowadays. The only real gripe I have is the fact that only wasmtime seems to fully support wasm32-wasip2. You can actually compile quite a lot of Rust backend stuff into WASM and run that instead of a container. Not that this is particularly useful, but I've found it interesting as an exercise.
The biggest blunder was not adding UTF-8 strings as a first class citizen
The second blunder was not allowing for any direct memory mapping I know it's against the security system but if you have to copy every pixel one by one to the host then that won't be effective
The third blunder was when they finally added GC objects to not make any of the objects properties readable from the host
At the last few places I've worked, we've seen most users engaging with our mobile app, and so it has made sense to develop a mobile app with flutter or kotlin multiplatform (or similar) for our broad userbase and then to use good ol' backed templated HTML for administrative sites rather than an SPA. Doing backend templating with good ol forms and what not is still a pretty good way to develop normal, boring websites.
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.
Compilation target support from Go and other languages makes it really easy to provide your library to websites - which we use for demos. It's quick to compile Go code into WASM and show folks quickly what your library offers.
Plus the demo's computation happens client side so no data is sent to a server.
We can offer our full payment parsing libraries to the web as developer tools without any code changes. I don't have to care about the details of WASM because it "just works".
To more examples of web assembly
Photoshop Online:
https://www.adobe.com/products/photoshop/online.html
And just announced
Unity Online:
> 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 article didn't even seriously entertain replacing JavaScript as an idea, saying nothing about why it's "very unlikely." But it's the #1 thing most devs are excited about in WASM: maybe they could ditch JS and use another language instead for browser UI, at least Rust, but maybe Go or even Python.
The reason that's unlikely is that browser UI is defined in standards as a JavaScript API; restandardizing an ABI for low-level languages would take years (perhaps decades). https://danfabulich.medium.com/webassembly-wont-get-direct-d...
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.
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.
WASM (and WebGL) seems to have powered Figma to a $20 billion aquisition offer by Adobe a while ago ; )
It's a fantastic item for the browser toolbox, and i agree with Amea that the "hallmark of success" has been achieved by this technology
I just wish wasm had some kind of api for drawing on a canvas, managing pointer/touch events and provide some accessibility apis. That's all I wanted and I believe also need for ditching altogether dom and other horrendous apis and start making real native like apps in the browser
The use case I always envisioned from the sidelines was that I could ditch a poorly designed, garbage-collected mess of a language (JavaScript) for something typesafe, with predictable performance, cache locality by default (as in not making everything a reference), no GC, generics, etc. But WASM won't be there until it has first-class access to the DOM, in my opinion.
Shameless plug: if you're interested in learning WebAssembly — like really learning the bytecode format and how it works — you might like our book, WebAssembly from the Ground Up: https://wasmgroundup.com.
It starts with handcrafted bytecode for a minimal Wasm module in JavaScript, and then guides you through the creation of a simple compiler for a toy language.
I'm usually pretty good at explaining new technologies to people but WebAssembly has got to be the most difficult to try and explain. The sheer number of misunderstandings about it is amazing. Luckily the misunderstandings serve my purpose for right now so I'm glad to see all the noise.
I recently wrote an eigenvalue solver for an interactive component on my blog with Rust compiled to WebAssembly. Being able to write-once and compile for the web and desktop felt like the future. But then, I'm no fan of JavaScript and wouldn't have attempted it if WASM didn't exist.
> Figma runs untrusted user plugins in your browser by running them in a QuickJS engine that is compiled to Wasm.
According to the linked blog article, this is not what they are doing, but rather an option they explored. They use JavaScript Realm shims to isolate the execution.
The author makes beautiful concise statements that make me feel like he has a deep, big-picture kind of understanding of computing.
I think this person would be very satisfying to work with, because decisions would be based on a discussion of tradeoffs, and an awareness of similar technologies and approaches throughout computing history.
>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."
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.
Going back a decade I remember numerous comments, in here and Reddit, from developers (typically Java developers) completely desperate for WASM to be a JavaScript replacement. This was despite the design goals of WASM literally stating the opposite.
Otherwise, WASM looks like a complete success.
I use webassembly for Substrata (https://substrata.info/). It works pretty well, allows building a c++ app using OpenGL for the web.
There is an intriguing alternative to WASM for many use cases: a RISC-V VM.
"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.
comes to my mind, but there must be more.
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.
I use WASM extensively in my OSS work with Filestash (https://github.com/mickael-kerjean/filestash ) in 3 main areas:
1. to create web versions of applications that are traditionally desktop only to render things like Parquet, PSD, TIFF, SQLite, EPS, ZIP, TGZ, and many more, where C libraries are often the reference implementations. There are almost a hundred supported file formats, most of which are supported through WASM: https://github.com/mickael-kerjean/filestash?tab=readme-ov-f...
2. to create plugins that extend the core application. As of today, you can add your own endpoint or middleware in Filestash, package it with its own manifest, and run server-side code in a constrained environment. For example, there is a libreoffice wasm edition that can run from your browser but requires a couple HTTP headers to be sent by the server to work so the plugin has this bit that run server side to add those HTTP headers: https://github.com/mickael-kerjean/filestash/blob/master/ser...
3. in the workflow engine to enable people to run their own code in actions while ensuring they can't fuck everything up
The sandboxification of WASM is what happened
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
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
November 2025 was when AntiGravity and Gemini 3 came out and everything changed for me. Six months earlier, I had tried to vibe-code the 21+ verification page to AgentDank (an OSS cannabis MCP server connecting LLMs to open data via DuckDB SQL). After hours, I couldn't get a page fully working.
I tried it with AG+G3, I prompted both the age 21+ screen AND the chat interface. It one-shotted a working version of both in less than a minute.
I was immediately free to start exploring my idea! Adding multiple personality Budtenders, a Stash box for frequent item; it would create mocks and tests. So liberating.
Then I had this other idea in my head for a while, that since DuckDB is broadly portable and can target WASM, I could play with the datasets in the browser and much of the app doesn't need an MCP-connected LLM or any backend services.
next up, there is another mode where we will browse and visualize the cannabinoid contents. the dataset will be the data here https://github.com/AgentDank/dank-data we will use apache echarts for visualizations. we can probably embed duckdb in the browser and do it all the queries there. we can have some simple UI for exploring, as well as raw SQL query
So WASM is gonna be as important as ever because we have tons of software which can be compiled to WASM, Web is the UX meeting point, and LLMs can help bring it all together.
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.