That's sad but sensical. Fun fact, Figma originally started as a fully C++ codebase, and Asm.js was key in proving that it would be possible to run a design tool in the browser. The switch to WebAssembly didn't happen until after there were paying customers, and provided nice improvements to load time (Asm.js is still JS which the bundle size is bigger and requires the code to be parsed into an AST, unlike WASM).
> 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.
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):
> 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 (?)
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.
(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.)
With this technology's death, the thread of prophecy is severed. Restore a saved game to restore the weave of fate, or persist in the doomed world you have created.
Not really: ASM.js became WASM. What killed the possibility of WASM being The One Way to run everything is AI... the one wildcard that Gard Bernhardt didn't predict.
I re-watch that presentation two or three times a year because it's a great example of how to give a presentation, how to structure your slide deck to complement your presentation, and a surprisingly educational tour of the permission rings architecture of operating systems.
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).
I’ll never forget watching Gary Bernhardt give his talk on JavaScript.[0] Was my introduction to asm.js, and the rabbithole associated with compiling code to run in the browser.
12 years on, it’s shocking how much of his fiction became reality.
And if not for the rise of AI it's possible that WASM as a machine-level compilation target for all languages might have happened. As much as Gary predicted he didn't see AI coming.
> But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead
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
This isn't a fair comparison. Wasm was severely limited when it was first implemented and it had the advantage of a decade of improvements. Asm.js has had zero improvements in that same time frame.
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.
IIRC Emscripten has removed asm.js support around 2020, and that was probably the most important toolchain that ever supported asm.js (maybe followed by Rust, don't know if they still support it though)
> 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.
Perhaps I'm misunderstanding, but doesn't asm.js have the same restrictions? I.e. you can't call web APIs directly from asm.js code, you still need special handling for "foreign" functions.
Depends how you want to look at it. On one side asm.js is just JavaScript with special JIT handling, so you should be able to mix them. On the other side you have C/C++/Rust/whatever compiled to asm.js which needs to go through hoops to call normal JavaScript code
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.
(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)
Binaryen used to have an asm2wasm tool, but I believe it has been deprecated. I couldn't find any other equivalent. At least the asm.js code will keep working even with asm.js opts disabled, but it would be nice to have a translator.
Just try the asm.js subset and see how it performs for you, I remember that even without the special asm.js support in browsers Emscripten output performance was surprisingly good
It will still work. asm.js is just regular JavaScript code, after all. It just won't parse/run as fast as custom pipeline for asm.js. My guess is that you will not notice much difference unless you have a really huge application.
In SpiderMonkey, asm.js code has been compiled by exactly the same pipeline as wasm since at least 2019. In fact, the way we compile it is literally to construct a pseudo-wasm module and run it through our wasm compiler (with a few flags to tweak the behavior to fit the asm.js semantics). In other words, if you're running asm.js in Firefox, you're literally just running wasm anyway, so how could it possibly be faster?
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.
Requires a secure origin. If you serve a local (but non-localhost) SPA over HTTP then you're blocked from using crypto.subtle.digest. At least, that is one reason I have seen a hand-rolled SHA-256 deployed.
Congratulations, two spectacularly wrong 'facts' in one short sentence is quite an achievement ;)
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).
Faster? I'm not sure about that. Maybe if you are doing a lot of talk between the compiled and JS runtime/DOM. But otherwise WASM has been much further developed in both Firefox and Chrome.
I don't think Chrome ever did an asm.js specific optimization.
Asm.js was never needed as a legacy mechanism, as it was just a compilation target for native code. There was nothing that it needed to remain backwards compatible with, all asm.js code was new code.
That's sad but sensical. Fun fact, Figma originally started as a fully C++ codebase, and Asm.js was key in proving that it would be possible to run a design tool in the browser. The switch to WebAssembly didn't happen until after there were paying customers, and provided nice improvements to load time (Asm.js is still JS which the bundle size is bigger and requires the code to be parsed into an AST, unlike WASM).
> 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.
What are the key differences between PNaCl and WASM?
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
> 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 (?)
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.
So the death of asm.js is upon us? We are drifting away from the timeline of the prophecy:
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.)
With this technology's death, the thread of prophecy is severed. Restore a saved game to restore the weave of fate, or persist in the doomed world you have created.
Not really: ASM.js became WASM. What killed the possibility of WASM being The One Way to run everything is AI... the one wildcard that Gard Bernhardt didn't predict.
I re-watch that presentation two or three times a year because it's a great example of how to give a presentation, how to structure your slide deck to complement your presentation, and a surprisingly educational tour of the permission rings architecture of operating systems.
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).
If we substituted war with COVID we aren't that far off.
Just substitute asm.js with WASM and you're still on the right track.
Don't worry, YavaScript will live forever.
I still refer to it as YavaScript much to the confusion of junior devs. I just tell the new kids: "you had to be there..."
I’ll never forget watching Gary Bernhardt give his talk on JavaScript.[0] Was my introduction to asm.js, and the rabbithole associated with compiling code to run in the browser.
12 years on, it’s shocking how much of his fiction became reality.
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
And if not for the rise of AI it's possible that WASM as a machine-level compilation target for all languages might have happened. As much as Gary predicted he didn't see AI coming.
I personally think this is a mistake. But I'm not sure how much it matters. It's not like a lot of people were using asm.js still AFAIK.
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.
> But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead
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...
This isn't a fair comparison. Wasm was severely limited when it was first implemented and it had the advantage of a decade of improvements. Asm.js has had zero improvements in that same time frame.
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.
> Asm.js has had zero improvements in that same time frame.
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.
IIRC Emscripten has removed asm.js support around 2020, and that was probably the most important toolchain that ever supported asm.js (maybe followed by Rust, don't know if they still support it though)
> 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.
Perhaps I'm misunderstanding, but doesn't asm.js have the same restrictions? I.e. you can't call web APIs directly from asm.js code, you still need special handling for "foreign" functions.
Depends how you want to look at it. On one side asm.js is just JavaScript with special JIT handling, so you should be able to mix them. On the other side you have C/C++/Rust/whatever compiled to asm.js which needs to go through hoops to call normal JavaScript code
> so you should be able to mix them
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.
Hmmm, need a asm.js -> WASM transpiler maybe.
(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)
Binaryen used to have an asm2wasm tool, but I believe it has been deprecated. I couldn't find any other equivalent. At least the asm.js code will keep working even with asm.js opts disabled, but it would be nice to have a translator.
Asm.js is dead! Long live WebAssembly!
To be fair, I thought asm.js was deprecated a few years ago with emergence of wasm.
We'll drink again in Valhalla (not the JDK project, the one with much carousing).
There goes my plan to use js code generation at runtime to make my algorithms faster. Doing this with wasm will be much harder.
Generating wasm code at runtime is pretty easy (I'd imagine easier than generating valid asm.js code). We have a little library for our tests that handles a lot of it: https://searchfox.org/firefox-main/source/js/src/jit-test/li...
There's still AssemblyScript? It might meet your requirements, unless I'm misunderstanding you or the features of it.
https://www.assemblyscript.org/
Just try the asm.js subset and see how it performs for you, I remember that even without the special asm.js support in browsers Emscripten output performance was surprisingly good
In fact, I think it was only firefox that made a special JIT route. Chrome moved optimizations into the regular JIT.
It will still work. asm.js is just regular JavaScript code, after all. It just won't parse/run as fast as custom pipeline for asm.js. My guess is that you will not notice much difference unless you have a really huge application.
There are some WAT compilers that are small and fast for running in the browser.
Never saw those monkey prints before
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."
Sad day. I have a sha256 hasher in asm.js that's faster than any wasm solution.
In SpiderMonkey, asm.js code has been compiled by exactly the same pipeline as wasm since at least 2019. In fact, the way we compile it is literally to construct a pseudo-wasm module and run it through our wasm compiler (with a few flags to tweak the behavior to fit the asm.js semantics). In other words, if you're running asm.js in Firefox, you're literally just running wasm anyway, so how could it possibly be faster?
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...
That is surprising. Do you know the reasons? Is it a special use case or was asm really faster? I find that hard to believe.
It's a custom solution, but nothing special just incremental hashing for large files.
I took off the shelf wasm crypto libraries to compare it, but the leading one was 10x slower.
can we see?
yeah check back at the end of the day.
will try to rip it out of the project and put it in a standalone benchmark.
It'd be interesting to compare it to a SHA-256 algorithm that uses Wasm simd: https://github.com/ChrisWhealy/wasm_sha256
Noted, will add that.
Last time I tried https://github.com/Daninet/hash-wasm
edit: I focus on browsers, that's wasm but not for browser envs.
what's wrong with the built in one?
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
Requires a secure origin. If you serve a local (but non-localhost) SPA over HTTP then you're blocked from using crypto.subtle.digest. At least, that is one reason I have seen a hand-rolled SHA-256 deployed.
asm.js is faster than WASM, and it can do everything that JS can do.
Congratulations, two spectacularly wrong 'facts' in one short sentence is quite an achievement ;)
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).
Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.
Faster? I'm not sure about that. Maybe if you are doing a lot of talk between the compiled and JS runtime/DOM. But otherwise WASM has been much further developed in both Firefox and Chrome.
I don't think Chrome ever did an asm.js specific optimization.
It did, V8 added asm.js compilation to WASM in 2017 https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-an...
How can a subset of JS do "everything" that JS can do?
All you need is a lambda
WASM wont improve if no one adopts it. Its a chicken and egg issue
WASM has been adopted and it has improved massively since 2017 though.
Asm.js was never needed as a legacy mechanism, as it was just a compilation target for native code. There was nothing that it needed to remain backwards compatible with, all asm.js code was new code.
https://acko.net/blog/on-asmjs/
o7