> asm.js was Mozilla’s response to the question posed by NaCl and PNaCl: how can the web run code at native speeds?
Had it been today, Chrome would have just pushed NaCl and PNaCl no matter what, and then everyone would complain why Safari and Firefox aren't keeping up with "Web" standards.
I still maintain the notion we're in the wrong timeline, one where PNaCl died and instead of a worthy, timely successor we end up being boiled alive in a soup of Electron apps.
I really thought, for a time, that we'd be doing everything in the browser. And in a way that's increasingly true, but it all just feels worse than ever. I like WASM and I want to like WASM but the rate of maturity within the ecosystem is incredibly abysmal.
What's worse is that we should all be running our untrustworthy AI tools and their outputs in precisely such a sandbox, and companies are selling the reverse: hosted sandboxes, hosted JS-based VMs.
I guess that was always the problem: there was never any money in a client-side sandbox.
I’ve found canvas + WebAssembly works great together!
Here’s an example of Sudoku running in WebAssembly (it was vibe coded in Zig) and then rendered to canvas. The interface between the wasm module and the browser is function calls for keyboard and mouse events, and then another that renders to a pixel buffer to copy to the canvas.
https://qip.dev/play-sudoku
And this approach also works for simple forms, such as a URL input that gets turned into a QR code. Again the interface is simple, here converted a URL into SVG markup. As you type in the input we call the WebAssembly render function again.
https://qip.dev/qr
The sudoku example has something massively wrong with it's performance. Latency is over a second per click and it halts after a few clicks.
The QR example works fine though
Do you really think this "works great"?
I'm using a brand-new MacBook Pro with a high-end M5 processor, and this site is extremely unresponsive for me. Huge latency between clicking and getting feedback.
It also breaks accessibility.
The QR code use case seems far more reasonable to me, you're generating a static image.
I wish we had another alternate timeline.
"Our submission is in TALx86, a strongly typed functional language that encourages an explicit continuation-passing style and supports mutually recursive modules. We were encouraged to use this language when we learned that the competition would allow us to run our program on an interpreter implemented in hardware. We are grateful to the Intel Corporation for developing this interpreter."
https://www.cs.cornell.edu/talc/icfp99-contest/solution.htm
Isn't this approximately just wasm?
Typed Assembly Language—fascinating. But since the software is "All rights reserved," I don't know if it can be used beyond personal use.
True, it was a dead end perhaps.
I do understand why NaCL and PNaCL are undesirable and why wasm is much better, but as a student the NaCL ssh app had saved my computer science homeworks more than once, and this is something that still doesn't have an alternative although I rarely would need it nowadays.
https://ssheasy.com/
https://www.google.com/search?q=wasm+ssh+client
...the future is here!
I think the whole NaCL thing was able to do the ssh directly from the browser without any tunneling, but maybe I am misremembering
What do you feel is immature in the WASM ecosystem right now?
Kindly give us performant access to the DOM, pretty-please! WITHOUT any JS glue code.
WASM is called WEB assembly but it can't access the Web API's without paying tax to the JS tyrant in between.
> Kindly give us performant access to the DOM, pretty-please! WITHOUT any JS glue code.
https://hacks.mozilla.org/2026/02/making-webassembly-a-first...
WASM standalone runtimes are mostly fine, but WASM in the browser is not great. No direct access to any web APIs (this often really hurts when shuffling data to/from WebGPU). Multithreading via WebWorkers is a complete pain to setup. No zero-copy APIs for streaming data in/out. Little paper cuts, but they all add up...
Memory management is pain. If you want to optimize, you're forced to 4k pages. Runtimes are fragmented. Wasi is a mess. Async and threading is awkward. Whenever you need to integrate with hardware you need platform specific adapters.
In practice, whenever you need more than a singlethreaded app with http/serial port, the "run everywhere" breaks.
Don't get me wrong I love WASM but we're not there yet
Not the previous poster, but immatures: Needing to compile down to one enormous program, with no possible code sharing. The async story is not good.
Wasm components & wasi have a lot of promise here. Until now though browsers have been ignoring all this; Firefox just started taking a more active interest. https://hacks.mozilla.org/2026/02/making-webassembly-a-first...
PNaCl was a terrible idea. It was as bad of an idea as shipping the raw sqlite interface in the browser.
I feel like some of the Google-sourced standards are the laziest, least-webby ones out there. There are some good ones that come from the Chrome team, but man the real stinkers are _always_ a lazy Google engineer trying to ship a half-baked clone of something native in the browser because they need it for something or other internally.
Its like natural selection, maybe not the best traits win overall but one that is the most popular choice because everyone is a webdev.
What are the key differences between PNaCl and WASM?
One of the big issues with NaCl is that the API it used wasn't standardized at all and there was only a single implementation. You could pick a random function and ask "hey, what happens if you pass in some slightly weird arguments?" and there was no answer beyond "whatever Chrome does". With enough work, maybe that could have been overcome while preserving backwards compatibility, but there were lots of random functions in there because somebody or other had found it useful. WASM was built from the ground up with a standards process and multiple implementations.
There were 3 systems, all with interesting differences.
The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox).
The next iteration was P(ortable)-NaCl which replaced the native machine code with a subset of LLVM bitcode, which was then compiled at load time. Unfortunately with this step NaCl lost most of its advantages. Startup time was atrocious because it was basically the second half of the LLVM compilation pipeline (from LLVM-IR to machine code). LLVM-IR also isn't actually great as CPU-agnostic bytecode.
WASM was designed from the ground up as CPU agnostic bytecode that's also much easier and faster to validate.
The only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement).
...apart from Emscripten => asm.js => WASM, and Google's NaCl/PNaCl there was also a system by Adobe (Flascc/Alchemy(?) I forgot all the names this went through) to compile C and C++ code into Adobe Flash bytecode.
I have an ancient blogpost from 2012 which compares the three (and where I have been flabbergasted by how well Emscripten actually worked - and this was even before asm.js - the linked demo is unfortunately no longer up):
https://floooh.github.io/2012/10/23/mea-culpa.html
> Alchemy
Yep, that's the name. There was a brief period in late 2000s when Adobe was pushing hard to make Flash embedded into web ecosystem. They made Air as a way to package Web or Flash code into a desktop app. Essentially it was Electron-before-Electron. Alchemy was a part of this grand plan to be able to integrate existing native libraries with Flash code. The plan was like you said to compile to Flash bytecode, and AFAIK it never went further than a tech demo.
This whole ecosystem turned into a slow train-wreck over approximately 5-year period. Adobe really saw themselves as future stewards of web technology. They donated their ActionScript VM and a JIT to Mozilla and hoped that Firefox would become the first browser with fast JavaScript engine. Google developed Chrome and V8 in secret and managed to release their fast browser early. Microsoft and Yahoo sabotaged adoption of ActionScript dialect as at the next JavaScript. And at the same time Apple went fully anti-plugins, and with the rise of iPhone both Flash and silverlight died off.
Years later Java folks tried to build their own version of Alchemy as part of GraalVM. The project was called Sulong and was using Graal to execute and JIT LLMV bitcode. TruffleRuby was supposed to be a primary early beneficiary to be able to compile and run Ruby native extensions. This was during the period of a race between several JIT solutions in hopes to become "the next Ruby", and Truffle team (along with IBM's OMR) lost the race first to MJIT and then to YJIT. Graal itself seems to loosing steam, because their multi-language VM never got enough adoption among Java, Node, or Ruby people, and the VM itself tended to use too much RAM in era when RAM became premium in the cloud.
> The only major advantage of PNaCl vs early WASM was that PNaCl supported shared-memory threading right from the start (this is still knee-capped in WASM because of the COOP/COEP response header requirement).
Presumably that is because PNaCl predated spectre (?)
Indeed, NaCl and PNaCl would have been hit by Meltdown/Spectre at least as badly as SharedArrayBuffer.
I remember early during the Wasm design process we were openly speculating whether people would eventually figure out how to do stuff like Rowhammer from raw Javascript. My bet was on Yes, but I don't remember if any of my teammates said No. I think we all knew the writing was on the wall by then.
> (Flascc/Alchemy(?) I forgot all the names this went through)
Crossbridge was its third and most recent name.
Pepper.js is another interesting project from around this time that didn't pan out.
https://github.com/google/pepper.js/
Wasn't pepper the P in PNaCl?
The P in PNaCl is Portable.
Pepper was a pun on Native Client (since NaCl = salt). Pepper Plugin API (PPAPI) was Google's more secure version of NPAPI (Netscape Plugin API). Flash Player was essentially the only thing using NPAPI/PPAPI by the end of its life.
The most common plugins were Flash, Silverlight, Adobe Reader, and the Java applet plugin, and I think all of those were in mildly common use when plugins were on their last legs.
Now you can have all of them running on top of WebAssembly, companies even pay for support.
> The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox).
Out of curiosity, does that mean that NaCL (without P) only ran on x86? Or were there different subsets for different architectures?
You could compile NaCL code for x86_64, aarch64, and aarch32 as well. Chrome apps has a system similar to mobile apps where you would upload an app with all binaries and users would get the one for their system architecture.
Ah, that makes sense. So users were effectively cross-compiling the NaCL binaries for multiple architectures.
I think the plan was to JIT x86 to other architectures.
Heh, emscripten. I remember running the Unreal engine in the browser with that. Quite impressive indeed.
> we should all be running our untrustworthy AI tools and their outputs in precisely such a sandbox
The DevOps infrastructure Kubernetes runbook AI inference router API people (DIK-AROUnders for short) always want an abstract technical solution that increases both their budget and their distance from the end user's actual application. Like the more money they get to dick around with meaningless technical cathedrals, the better. They're only bent out of shape that they couldn't parlay that into a sweet crypto scheme. In the real world, the line between what users actually want and what DIK-AROUnders call inauthentic activity is quite blurred.
To me, the fact that AI agents can browse websites and make payments and read my email and pretend to be me or other people is a huge part of their value proposition. People want to get out of the sandbox! There are many meanings to the words security and privacy.
That's not how I remember it: it was an experiment that was useful at the time but didn't work out. It was useful internally to sandbox Flash player, but the limitations of the LLVM based approach were soon evident to everyone involved.
I mean that's still basically what they tried to do at the time. They were trying to get them through web standards committees and everything.
IIRC a big reason it didn't end up working was because NaCl was such a "big" technology and asm.js such a "small" one that asm.js was able to reach production-ready first despite starting work several years later.
The big difference was that they lacked the market share they enjoy nowadays, with their forks and Electron crap.
The cute thing about asm.js is that it was fully backwards compatible with the web: it was just a lot slower without dedicated support. So Epic or whomever could put out a demo that would run just fine in Chrome, but the performance was a lot worse than Firefox which had a dedicated compilation pipeline, so it made Chrome look bad.
Exactly. "You can't not support it; you can only be slow."
People complain when there are no highly compatible alternatives to something that would be useful to have on the web platform. Asm.js and then Wasm were those alternatives. That's why they didn't complain then but do complain now about things that Safari won't do because it would hurt the App Store. Happily, the EU is now at least trying to whip Apple into shape.
You mean Chrome would have pushed it, Apple would have filibustered it by refusing to comment (via lack of investment in the WebKit team), and then gullible folks on the internet would defer to them.
(I will note that Apple seems to have upped WebKit investment this decade since their regulatory problems started in earnest - so it's possible this would end differently today)