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 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.
"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."
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.
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.
The QR example works fine though
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.
It gives a sandboxed directory on the local computer you can read and write to (user decides what rights you get). It's what the web version of VS Code uses to edit local files.
It's wonderful. Suddenly you can blend local and remote systems together the way they should operate, without having to have local apps with god-knows-what rights.
It's not implemented in Firefox. I understand it is a risky API, but wow it makes a huge difference to what is possible.
For example, I did this for a recent Kaggle comp: https://github.com/nlothian/gemma-data-agent
It runs Gemma E4B in the browser, and Python (Pyodide) and SQL (DuckDB) in WASM.
You can give it a directory with some CSVs, tell it to load them and then it can run analysis on them.
The whole Web platform is great - I just wish I could say it runs in Firefox too.
WASM is called WEB assembly but it can't access the Web API's without paying tax to the JS tyrant in between.
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
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...
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.
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):
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.
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.
(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)
Users were migrating to us _from_ desktop applications. Collaboration was the key differentiator, but a less well known reason was that improved performance, including but not limited to the support of large design systems, was also a commonly cited reason among paying customers for migrating to Figma.
Desktop or collaborative is a false dichotomy. Desktop or performance is too.
I get why you did what you did. It makes sense. But don’t think there aren’t people out here who HATE everything being shoved on the web with no desktop option.
No, electron and PWA don’t count.
Jokes aside, Figma's stack is super inspiring, and y'all's articles on sync engines heavily inspired my work on LegendKeeper. I appreciate the work you do!
https://www.destroyallsoftware.com/talks/the-birth-and-death...
(And to those who haven't encountered this before, I strongly recommend a watch. It may be the greatest tech talk of all time, for certain values of greatest.)
Its IR design is horrendeous.
And at some point we're going to have a period or war and our psychological attachments to old programming paradigms will be released so that we can move on to a more advanced way of doing things (but that won't stop your bank from running YavaScript for at least another 85 years).
12 years on, it’s shocking how much of his fiction became reality.
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
This sounds cursed, but customers loved it. Since it wasn't an EXE, it didn't get caught up in their employers' overzealous corporate IT filters. That's why we never switched to Electron. In a sense, we had some of the primeval elements of the thick app.
And this is still a killer feature of asm.js, even if it's not 'supported' it's still implicitly supported.
EDIT: And also seriously just thanks to the people who invented asm.js, it was a brilliant idea, but it makes sense that it's not worth optimizing anymore.
(compiling legacy code with legacy versions of Emscripten is quite frustrating, almost as bad as updating your JS code to be compatible with accumulated changes in the Emscripten ABI)
https://webglinsights.github.io/
It was fun to see the rise of asm.js, which was a precursor to Web Assembly. Some of the early demos were so cool to see; Unreal Engine running in the browser. :) Bitter sweet to see the sun set here, but it did lead to much better things.
Nowadays most browser JavaScript VMs converged to very similar designs and optimizations, so even without Odin asm.js code would run pretty fast anyway.
But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead.
But I wasn't sure that emscripten still fully supported it.
You can't call most web apis from wasm.
But more important for what i was trying to do, you can't zero copy buffers from js to wasm.
Everything is a trade off. The isolation is a good thing, but also a bad thing.
asmjs is going to be strictly more limited in interacting with JS than wasm. You're basically limited to simple number values and array buffers. Whereas wasm now a days has GC types and can hold onto JS value using externref.
> But more important for what i was trying to do, you can't zero copy buffers from js to wasm
I'm pretty sure you can't do that with asmjs either. There is a proposal for zero-copy buffers with wasm: https://github.com/WebAssembly/memory-control/blob/main/prop...
Had WASM not been adopted we would have SIMD in JS ( probably via asm.js) by now. Because we didn't, JS just cannot compete with WASM in many computationally heavy workflows. We'd also have general purpose JS to Asm.js compilation, with few API restrictions, making writing it much easier.
WASM is that evolution of (strict mode) asm.js. The two really aren't all that different from what they can and can't do.
But since asm.js is just (a subset of) javascript, I assumed I could just pass ArrayBuffers around.
With wasm, I could pass a Uint8Array out of it. If I wanted to pass it in, I had to call malloc from the javascript side to allocate in the wasm heap. But since I already had an arraybuffer (from a file upload), that meant an extra copy.
> You can't call most web apis from wasm.
You can't from strict asm.js either, since it only supports numbers (no JS strings or objects) and manages the C heap in an ArrayBuffer object just like WASM.
> But more important for what i was trying to do, you can't zero copy buffers from js to wasm.
Same problem as above, you need to call out into "real" Javascript from asm.js and you can't map other ArrayBuffers directly into the 'asm.js heap' either, a copy is needed. The "Javascript FFI" really isn't much different between asm.js and WASM.
AFAIK as soon as you'd start mixing idiomatic JS and asm.js, you lose the "special sauce", you only got the special asm.js treatment in browsers when putting a "use asm" at the top of a source file, and that would prevent using regular JS features in the same file.
> An asm.js module can take up to three optional parameters, providing access to external JavaScript code and data:
> - a standard library object, providing access to a limited subset of the JavaScript standard libraries;
> - a foreign function interface (FFI), providing access to custom external JavaScript functions; and
> - a heap buffer, providing a single ArrayBuffer to act as the asm.js heap.
From http://asmjs.org/spec/latest/#introduction:~:text=External%2...
In asm.js you have to treat JS functions and objects as special extern values, just like in WASM.
asm.js - when validated and optimized - is closer to WASM serialized to a JS-like syntax than actual JS.
https://monkeyink.com/ink/blog/archives/2016/08/_this_is_a_f...
"The image is a collage of antique open source art reflecting the open source code."
While in JS you would probably use https://www.npmjs.com/package/binaryen
this was such a crazy project. remember when we compiled our c++ to wasm over 10 years ago, wait, this works?! web seemed to move so fast then.
It allowed it to be an experiment that could have been quickly rolled out without a risk of forever lingering as a back-compat requirement for browsers.
Furthermore, if you use wasm, you'll have fewer bounds checks (because of better memory allocation strategies[1]), access to SIMD, bulk memory operations, and a host of other niceties that have been added to wasm over the years. If your asm.js code is outperforming someone else's wasm code, that probably just means their wasm code is worse.
[1]: https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
wasm hashing in chrome is half the speed of firefox for me.
I took off the shelf wasm crypto libraries to compare it, but the leading one was 10x slower.
https://theultdev.github.io/web-sha256-benchmark
https://github.com/TheUltDev/web-sha256-benchmark
It's Chrome wasm (windows) that is slow for me, 2x slower than asmjs.
FF with asmjs optimizations are 2x slower than wasm on FF.
Wasm in FF is 2x faster than wasm in Chrome for this hashing solution (for me).
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
Edit: oh, and it forces async.
I do use it for smaller files though, it's much faster.
It's true that in the beginning (around 2017), WASM wasn't much faster than asm.js, but meanwhile WASM has seen real performance improvements.
Featurewise, asm.js is much closer to WASM than to regular JS, it definitely cannot do everything that regular JS can do (mainly because asm.js is limited to the Number type, it cannot deal with JS strings or objects).
I don't think Chrome ever did an asm.js specific optimization.
We still need to download half Internet for emscripten, plus whatever tools are being used on top. Although it is somewhat simpler for those that build on top of binaren.
