10 ms·

Saying goodbye to asm.js

410 points by eqrion 5mo ago

theultdev 5mo ago
Sad day. I have a sha256 hasher in asm.js that's faster than any wasm solution.
- lukan 5mo ago
  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.
  - theultdev 5mo ago
    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.
    - throawayonthe 5mo ago
      can we see?
      - theultdev 5mo ago
        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.
        titzer 5mo ago
        It'd be interesting to compare it to a SHA-256 algorithm that uses Wasm simd: https://github.com/ChrisWhealy/wasm_sha256 https://github.com/ChrisWhealy/wasm_sha256
        theultdev 5mo ago
        Noted, will add that. Last time I tried https://github.com/Daninet/hash-wasm https://github.com/Daninet/hash-wasm edit: I focus on browsers, that's wasm but not for browser envs. ---- https://theultdev.github.io/web-sha256-benchmark https://theultdev.github.io/web-sha256-benchmark https://github.com/TheUltDev/web-sha256-benchmark https://github.com/TheUltDev/web-sha256-benchmark seems it is chrome wasm that is slow. asmjs is about the same speed in chrome and firefox (with asm optimizations still enabled) but wasm is slow as hell in chrome, asm still better. side note: someone mentioned native crypto.subtle, but that doesn't have incremental hashing so can't use it for large files. however I do use it in practice for smaller files.
- bvisness 5mo ago
  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-actually-worth-using.html https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
  - theultdev 5mo ago
    yeah turns out it was chrome that was slow, not firefox. wasm hashing in chrome is half the speed of firefox for me. https://theultdev.github.io/web-sha256-benchmark https://theultdev.github.io/web-sha256-benchmark
- dist-epoch 5mo ago
  what's wrong with the built in one? https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
  - wren6991 5mo ago
    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. Edit: oh, and it forces async.
  - theultdev 5mo ago
    no incremental hashing, so you can't hash files too large for ram. I do use it for smaller files though, it's much faster.
- theultdev 5mo ago
  Made the requested benchmark: https://theultdev.github.io/web-sha256-benchmark https://theultdev.github.io/web-sha256-benchmark https://github.com/TheUltDev/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).
koolala 5mo ago
Never saw those monkey prints before https://monkeyink.com/ink/blog/archives/2016/08/_this_is_a_fun.php 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."
- dblohm7 5mo ago
  The SpiderMonkey team always had t-shirts made up of these.
css_apologist 5mo ago
o7
stkdump 5mo ago
There goes my plan to use js code generation at runtime to make my algorithms faster. Doing this with wasm will be much harder.
- giancarlostoro 5mo ago
  There's still AssemblyScript? It might meet your requirements, unless I'm misunderstanding you or the features of it. https://www.assemblyscript.org/ https://www.assemblyscript.org/
- koolala 5mo ago
  There are some WAT compilers that are small and fast for running in the browser.
- titzer 5mo ago
  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.
- flohofwoe 5mo ago
  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
  - cogman10 5mo ago
    In fact, I think it was only firefox that made a special JIT route. Chrome moved optimizations into the regular JIT.
- eqrion 5mo ago
  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/lib/wasm-binary.js#1 https://searchfox.org/firefox-main/source/js/src/jit-test/li...
drob518 5mo ago
Asm.js is dead! Long live WebAssembly!
- deleted 5mo ago
  [deleted]
- ivanjermakov 5mo ago
  To be fair, I thought asm.js was deprecated a few years ago with emergence of wasm.
metmac 5mo ago
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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- mikece 5mo ago
  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.
  - chamomeal 5mo ago
    wait how did AI impede wasm?
    - xscott 5mo ago
      I believe the idea is that you don't care what language is being used if you aren't going to look at it anyway. Given that premise, the AI can write JavaScript instead of something you need to compile separately.
      - esperent 5mo ago
        WASM is hard enough to use that I would say the number of people using it just because they don't like JS/TS is fairly small. At least that's always been my impression. If you're willing to go through the effort to use it, it's probably because you need the performance gains, and AI hasn't changed that.
- ryukoposting 5mo ago
  The bit about "thick apps" always stuck with me. Partly because the name is funny, partly because it hit close to home. The first time I saw his talk, I was an intern working for a company that had built an entire compiler, IDE, and debugger in-house for their little industrial IO boxes. The compiler was written in C, and we used Emscripten to turn it into some JS that then got "compiled" (see: concatenated) into a giant HTML file with the IDE and debugger bits. Code uploads and debugging happened over ethernet, so all of that just got shoved through Ajax. 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.
futune 5mo ago
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-of-javascript 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.)
- phoe-krk 5mo ago
  Just substitute asm.js with WASM and you're still on the right track.
- muvlon 5mo ago
  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.
  - mikece 5mo ago
    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.
    - DarkUranium 5mo ago
      To be honest, with how bad a target WASM is for any existing compiler, I feel like what killed that possibility was WASM itself. Its IR design is horrendeous.
      - nextaccountic 5mo ago
        Can you talk more? I've seen people say only good things about wasm
        avadodin 5mo ago
        Not op, but I only know it as the 32-bit single-threaded binary replacement for JavaScript that can't interact with anything naturally yet people get all excited about when they manage to turn their LLVM slop output into it. Maybe we've been reading different HN submissions.
unconed 5mo ago
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/ https://acko.net/blog/on-asmjs/
- pornel 5mo ago
  OTOH asm.js can be retired now thanks to being backwards compatible with plain JS. 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.
looneysquash 5mo ago
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.
- eqrion 5mo ago
  > 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/proposals/memory-control/Overview.md https://github.com/WebAssembly/memory-control/blob/main/prop...
  - davidmurdoch 5mo ago
    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.
    - flohofwoe 5mo ago
      > 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.
sehugg 5mo ago
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)
- eqrion 5mo ago
  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.
- JoshTriplett 5mo ago
  https://porffor.dev/ https://porffor.dev/
- Kaxo 5mo ago
  In chrome at least asm.js is(/was?) handled by the wasm engine anyway. They essentially did that transpiling at load time.
oneshtein 5mo ago
asm.js is faster than WASM, and it can do everything that JS can do.
- cogman10 5mo ago
  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.
  - nightpool 5mo ago
    It did, V8 added asm.js compilation to WASM in 2017 https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-and-compiled-to-webassembly https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-an...
- mbrock 5mo ago
  Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.
- chilmers 5mo ago
  How can a subset of JS do "everything" that JS can do?
  - bogdan 5mo ago
    All you need is a lambda
- ramon156 5mo ago
  WASM wont improve if no one adopts it. Its a chicken and egg issue
  - flohofwoe 5mo ago
    WASM has been adopted and it has improved massively since 2017 though.
pjmlp 5mo ago
> 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.
- xyzzy_plugh 5mo ago
  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.
  - tardedmeme 5mo ago
    What are the key differences between PNaCl and WASM?
    - flohofwoe 5mo ago
      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 https://floooh.github.io/2012/10/23/mea-culpa.html
rudi-c 5mo ago
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).
- 0x457 5mo ago
  What's so sad about it? It was just a compilation target that made sense at one point in time. Its like being sad about i386-unknown-freebsd1 being dropped.
  - rudi-c 5mo ago
    Yes, I don't mean that it affects the present. Only sad in a nostalgia sense.
- frumplestlatz 5mo ago
  What’s sad about that is we could have had a clean, native, desktop Figma application.
  - rudi-c 5mo ago
    This is a lazy statement based on extremely vague handwaving about desktop v.s. web. It's not the 2010s anymore. Time to drop these generalities. 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.
    - MBCook 5mo ago
      Users still care. 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.
EdwardDiego 5mo ago
We'll drink again in Valhalla (not the JDK project, the one with much carousing).
claytongulick 5mo ago
It would have been nice if they had mentioned Luke Wagner, who's idea it all was and who created the first implementation, as well as one of the main driving forces behind wasm.
hollowturtle 5mo ago
Isn't Asm.js better just for the fact that I can call web apis directly without shims? Or moving data in and out? I'd love to commit totally to webassembly but still seems very limited, am I wrong?
- aabhay 5mo ago
  Wasm can also call web apis directly. The overhead you hear about is in translating complex types like nested dicts etc between formats. But wasm runs inside the js runtime
  - nextaccountic 5mo ago
    There's a real overhead in that wasm can't inline those calls, but Javascript can
- 0x457 5mo ago
  Depends on what do you mean about by web apis. Fetch API for example is not part of asm.js subset of JavaScript. You going to need a javascript shim on both cases. However, like the siblings comment says: overhead comes from conversion between big structures.
ndesaulniers 5mo ago
A long time ago, I wrote a small chapter in a WebGL book on asm.js. https://webglinsights.github.io/ 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.
danborn26 5mo ago
[dead]
andrewl-hn 5mo ago
I remember when Mozilla released OdinMonkey that was hyper-specialized for asm.js code, the Chrome / V8 team instead worked on general-purpose optimizations in their JIT that would run normal JavaScript faster but also would help asm.js. The difference in speed was 2-4x in favor of Firefox, and they hyped it a lot :D Nowadays most browser JavaScript VMs converged to very similar designs and optimizations, so even without Odin asm.js code would run pretty fast anyway.
trgn 5mo ago
:( 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.
karel-3d 5mo ago
What I liked about asm.js is that it's "just" javascript and you don't need any special way to load them, while with wasm you have the wasm file which you need to load on the side, which is a bit clunkier. But eh it's a tiny thing
richardfey 5mo ago
I'd be interested in seeing how worse the Epic Citadel demo will perform with this removal.
veltas 5mo ago
> If you maintain a site that uses asm.js, nothing will break. asm.js is just a subset of plain JavaScript, so the code keeps running through our regular JIT just like any other script. 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.

410 points by eqrion 5mo ago

theultdev 5mo ago

Sad day. I have a sha256 hasher in asm.js that's faster than any wasm solution.

lukan 5mo ago
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.
- theultdev 5mo ago
  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.
  - throawayonthe 5mo ago
    can we see?
    - theultdev 5mo ago
      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.
      - titzer 5mo ago
        It'd be interesting to compare it to a SHA-256 algorithm that uses Wasm simd: https://github.com/ChrisWhealy/wasm_sha256 https://github.com/ChrisWhealy/wasm_sha256
        theultdev 5mo ago
        Noted, will add that. Last time I tried https://github.com/Daninet/hash-wasm https://github.com/Daninet/hash-wasm edit: I focus on browsers, that's wasm but not for browser envs. ---- https://theultdev.github.io/web-sha256-benchmark https://theultdev.github.io/web-sha256-benchmark https://github.com/TheUltDev/web-sha256-benchmark https://github.com/TheUltDev/web-sha256-benchmark seems it is chrome wasm that is slow. asmjs is about the same speed in chrome and firefox (with asm optimizations still enabled) but wasm is slow as hell in chrome, asm still better. side note: someone mentioned native crypto.subtle, but that doesn't have incremental hashing so can't use it for large files. however I do use it in practice for smaller files.
bvisness 5mo ago
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-actually-worth-using.html https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
- theultdev 5mo ago
  yeah turns out it was chrome that was slow, not firefox. wasm hashing in chrome is half the speed of firefox for me. https://theultdev.github.io/web-sha256-benchmark https://theultdev.github.io/web-sha256-benchmark
dist-epoch 5mo ago
what's wrong with the built in one? https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
- wren6991 5mo ago
  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. Edit: oh, and it forces async.
- theultdev 5mo ago
  no incremental hashing, so you can't hash files too large for ram. I do use it for smaller files though, it's much faster.
theultdev 5mo ago
Made the requested benchmark: https://theultdev.github.io/web-sha256-benchmark https://theultdev.github.io/web-sha256-benchmark https://github.com/TheUltDev/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).

koolala 5mo ago

Never saw those monkey prints before https://monkeyink.com/ink/blog/archives/2016/08/_this_is_a_fun.php 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."

dblohm7 5mo ago
The SpiderMonkey team always had t-shirts made up of these.

css_apologist 5mo ago

stkdump 5mo ago

There goes my plan to use js code generation at runtime to make my algorithms faster. Doing this with wasm will be much harder.

giancarlostoro 5mo ago
There's still AssemblyScript? It might meet your requirements, unless I'm misunderstanding you or the features of it. https://www.assemblyscript.org/ https://www.assemblyscript.org/
koolala 5mo ago
There are some WAT compilers that are small and fast for running in the browser.
titzer 5mo ago
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.
flohofwoe 5mo ago
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
- cogman10 5mo ago
  In fact, I think it was only firefox that made a special JIT route. Chrome moved optimizations into the regular JIT.
eqrion 5mo ago
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/lib/wasm-binary.js#1 https://searchfox.org/firefox-main/source/js/src/jit-test/li...

drob518 5mo ago

Asm.js is dead! Long live WebAssembly!

deleted 5mo ago
[deleted]
ivanjermakov 5mo ago
To be fair, I thought asm.js was deprecated a few years ago with emergence of wasm.

metmac 5mo ago

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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

mikece 5mo ago
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.
- chamomeal 5mo ago
  wait how did AI impede wasm?
  - xscott 5mo ago
    I believe the idea is that you don't care what language is being used if you aren't going to look at it anyway. Given that premise, the AI can write JavaScript instead of something you need to compile separately.
    - esperent 5mo ago
      WASM is hard enough to use that I would say the number of people using it just because they don't like JS/TS is fairly small. At least that's always been my impression. If you're willing to go through the effort to use it, it's probably because you need the performance gains, and AI hasn't changed that.
ryukoposting 5mo ago
The bit about "thick apps" always stuck with me. Partly because the name is funny, partly because it hit close to home. The first time I saw his talk, I was an intern working for a company that had built an entire compiler, IDE, and debugger in-house for their little industrial IO boxes. The compiler was written in C, and we used Emscripten to turn it into some JS that then got "compiled" (see: concatenated) into a giant HTML file with the IDE and debugger bits. Code uploads and debugging happened over ethernet, so all of that just got shoved through Ajax. 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.

futune 5mo ago

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-of-javascript 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.)

phoe-krk 5mo ago
Just substitute asm.js with WASM and you're still on the right track.
muvlon 5mo ago
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.
- mikece 5mo ago
  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.
  - DarkUranium 5mo ago
    To be honest, with how bad a target WASM is for any existing compiler, I feel like what killed that possibility was WASM itself. Its IR design is horrendeous.
    - nextaccountic 5mo ago
      Can you talk more? I've seen people say only good things about wasm
      - avadodin 5mo ago
        Not op, but I only know it as the 32-bit single-threaded binary replacement for JavaScript that can't interact with anything naturally yet people get all excited about when they manage to turn their LLVM slop output into it. Maybe we've been reading different HN submissions.

unconed 5mo ago

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/ https://acko.net/blog/on-asmjs/

pornel 5mo ago
OTOH asm.js can be retired now thanks to being backwards compatible with plain JS. 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.

looneysquash 5mo ago

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.

eqrion 5mo ago
> 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/proposals/memory-control/Overview.md https://github.com/WebAssembly/memory-control/blob/main/prop...
- davidmurdoch 5mo ago
  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.
  - flohofwoe 5mo ago
    > 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.

sehugg 5mo ago

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)

eqrion 5mo ago
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.
JoshTriplett 5mo ago
https://porffor.dev/ https://porffor.dev/
Kaxo 5mo ago
In chrome at least asm.js is(/was?) handled by the wasm engine anyway. They essentially did that transpiling at load time.

oneshtein 5mo ago

asm.js is faster than WASM, and it can do everything that JS can do.

cogman10 5mo ago
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.
- nightpool 5mo ago
  It did, V8 added asm.js compilation to WASM in 2017 https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-and-compiled-to-webassembly https://v8.dev/blog/v8-release-61#asm.js-is-now-validated-an...
mbrock 5mo ago
Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.
chilmers 5mo ago
How can a subset of JS do "everything" that JS can do?
- bogdan 5mo ago
  All you need is a lambda
ramon156 5mo ago
WASM wont improve if no one adopts it. Its a chicken and egg issue
- flohofwoe 5mo ago
  WASM has been adopted and it has improved massively since 2017 though.

pjmlp 5mo ago

> 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.

xyzzy_plugh 5mo ago
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.
- tardedmeme 5mo ago
  What are the key differences between PNaCl and WASM?
  - flohofwoe 5mo ago
    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 https://floooh.github.io/2012/10/23/mea-culpa.html

rudi-c 5mo ago

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).

0x457 5mo ago
What's so sad about it? It was just a compilation target that made sense at one point in time. Its like being sad about i386-unknown-freebsd1 being dropped.
- rudi-c 5mo ago
  Yes, I don't mean that it affects the present. Only sad in a nostalgia sense.
frumplestlatz 5mo ago
What’s sad about that is we could have had a clean, native, desktop Figma application.
- rudi-c 5mo ago
  This is a lazy statement based on extremely vague handwaving about desktop v.s. web. It's not the 2010s anymore. Time to drop these generalities. 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.
  - MBCook 5mo ago
    Users still care. 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.

EdwardDiego 5mo ago

We'll drink again in Valhalla (not the JDK project, the one with much carousing).

claytongulick 5mo ago

It would have been nice if they had mentioned Luke Wagner, who's idea it all was and who created the first implementation, as well as one of the main driving forces behind wasm.

hollowturtle 5mo ago

Isn't Asm.js better just for the fact that I can call web apis directly without shims? Or moving data in and out? I'd love to commit totally to webassembly but still seems very limited, am I wrong?

aabhay 5mo ago
Wasm can also call web apis directly. The overhead you hear about is in translating complex types like nested dicts etc between formats. But wasm runs inside the js runtime
- nextaccountic 5mo ago
  There's a real overhead in that wasm can't inline those calls, but Javascript can
0x457 5mo ago
Depends on what do you mean about by web apis. Fetch API for example is not part of asm.js subset of JavaScript. You going to need a javascript shim on both cases. However, like the siblings comment says: overhead comes from conversion between big structures.

ndesaulniers 5mo ago

A long time ago, I wrote a small chapter in a WebGL book on asm.js. https://webglinsights.github.io/ 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.

danborn26 5mo ago

[dead]

andrewl-hn 5mo ago

I remember when Mozilla released OdinMonkey that was hyper-specialized for asm.js code, the Chrome / V8 team instead worked on general-purpose optimizations in their JIT that would run normal JavaScript faster but also would help asm.js. The difference in speed was 2-4x in favor of Firefox, and they hyped it a lot :D Nowadays most browser JavaScript VMs converged to very similar designs and optimizations, so even without Odin asm.js code would run pretty fast anyway.

trgn 5mo ago

:( 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.

karel-3d 5mo ago

What I liked about asm.js is that it's "just" javascript and you don't need any special way to load them, while with wasm you have the wasm file which you need to load on the side, which is a bit clunkier. But eh it's a tiny thing

richardfey 5mo ago

I'd be interested in seeing how worse the Epic Citadel demo will perform with this removal.

veltas 5mo ago

> If you maintain a site that uses asm.js, nothing will break. asm.js is just a subset of plain JavaScript, so the code keeps running through our regular JIT just like any other script. 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.