alt.hn

5/20/2026 at 12:01:56 PM

Saying goodbye to asm.js

 https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-asmjs.html

by eqrion

5/20/2026 at 2:35:10 PM

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

by pjmlp

5/20/2026 at 2:58:39 PM

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.

by xyzzy_plugh

5/21/2026 at 5:27:15 AM

I've been using the FileSystems API a lot lately.

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.

by nl

5/20/2026 at 5:50:44 PM

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

by projektfu

5/20/2026 at 11:48:09 PM

Typed Assembly Language—fascinating. But since the software is "All rights reserved," I don't know if it can be used beyond personal use.

by cylinder714

5/21/2026 at 12:04:07 AM

True, it was a dead end perhaps.

by projektfu

5/21/2026 at 1:52:07 AM

Isn't this approximately just wasm?

by nextaccountic

5/21/2026 at 11:06:20 AM

Is there hardware that executes WASM directly?

by projektfu

5/20/2026 at 10:32:11 PM

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

by burntcaramel

5/20/2026 at 11:23:47 PM

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

by spartanatreyu

5/21/2026 at 5:40:37 PM

Thanks, I had shipped a bug in the event system. The performance should be much improved now.

by burntcaramel

5/20/2026 at 11:06:49 PM

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.

by dmazzoni

5/21/2026 at 5:46:42 PM

It definitely wasn’t “working great”, I’ve now fixed a bug in the event system that was causing loops. The performance should be improved now.

Yes, accessibility is a key concern of mine, I’m keen to explore html-in-canvas as a way to have an accessibility tree combined with a rendered interaction.

I’m personally at a stage where React and CSS have pushed to DOM to extremes of complexity and difficultly in optimization that I desire simpler ARIA-based HTML combined with custom rendering. I’m hopeful that it will be easier to test, lighter for users, and faster for everyone.

by burntcaramel

5/20/2026 at 3:56:41 PM

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.

by alex7o

5/20/2026 at 6:02:44 PM

What do you feel is immature in the WASM ecosystem right now?

by kettlecorn

5/20/2026 at 7:05:30 PM

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.

by lenkite

5/20/2026 at 7:25:37 PM

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

by swiftcoder

5/20/2026 at 7:17:21 PM

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

by po1nt

5/20/2026 at 6:15:12 PM

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

by jauntywundrkind

5/21/2026 at 9:55:43 AM

Probably an unpopular opinion, but IMHO the WASM Component Model is an entirely overengineered boondoggle that has no place in browsers.

It's trivial to create small statically linked WASM programs in the "a few dozen kilobytes" range with the right programming language (like C).

"Code sharing" via dynamic linking also works, but it has the same downsides as dynamic linking on native platforms (basically that DLL interfaces represent an optimization barrier): https://emscripten.org/docs/compiling/Dynamic-Linking.html

by flohofwoe

5/20/2026 at 9:00:32 PM

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.

by mmastrac

5/21/2026 at 11:00:13 AM

i care about it more than money, here's my take on a client-side `sandbox`: https://github.com/smol-machines/smolvm

it's a lightweight vm because i see sandboxing as a feature of vm's.

by binsquare

5/20/2026 at 4:27:27 PM

Its like natural selection, maybe not the best traits win overall but one that is the most popular choice because everyone is a webdev.

by hoppp

5/20/2026 at 3:12:22 PM

What are the key differences between PNaCl and WASM?

by tardedmeme

5/20/2026 at 7:42:22 PM

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.

by mccr8

5/20/2026 at 3:21:03 PM

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

by flohofwoe

5/20/2026 at 6:44:16 PM

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

by andrewl-hn

5/21/2026 at 9:43:48 AM

Graal was never designed as OpenJDK replacement, it is the evolution of MaximeVM, and their main customers, meaning who pays the team salaries are the Oracle database and cloud teams.

In that regard they are doing pretty well.

Plus all the folks that never paid for ExcelsiorJET, JRockit, PTC, Aicas, and many others of which only PTC and Aicas survive, now have in Graal their gratis AOT compiler.

Alongside OpenJ9 (which is more like what Leyden is trying to be), and the one on the box shipped alongside ART.

Ruby on top of JVM has a few interwined stories since the days Sun embraced it on Netbeans, and it suffers from the same issues as PyPy regarding adoption, it suffices not to be 100% compatible with whatever crazy extensions written in C exist out there.

Microsoft was probably more clever giving up on IronPython and IronRuby, and keeping the DLR infrastructure.

by pjmlp

5/21/2026 at 4:28:44 PM

In my experience JRuby is way more viable than Jython ever was, one because Ruby native modules were more often thin wrappers, two because Ruby has sorta-standard in form of test suite (which AFAIK evolved from one that was necessary for ISO Ruby effort), and established somewhat case of using different implementations..

And C extensions never got as crazy as in python, and some major ones either made Java backends or switched from MRI embedding to FFI

by p_l

5/20/2026 at 4:42:28 PM

> (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/

by Randomno

5/20/2026 at 4:49:16 PM

Wasn't pepper the P in PNaCl?

by Yoric

5/20/2026 at 5:00:18 PM

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.

by Randomno

5/20/2026 at 5:22:49 PM

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.

by jcranmer

5/20/2026 at 8:18:53 PM

Now you can have all of them running on top of WebAssembly, companies even pay for support.

by pjmlp

5/20/2026 at 3:35:13 PM

> 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 (?)

by bawolff

5/20/2026 at 3:40:57 PM

Indeed, NaCl and PNaCl would have been hit by Meltdown/Spectre at least as badly as SharedArrayBuffer.

by flohofwoe

5/20/2026 at 6:48:44 PM

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.

by kg

5/20/2026 at 6:06:48 PM

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

by xg15

5/20/2026 at 7:25:54 PM

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.

by wffurr

5/20/2026 at 10:25:03 PM

Ah, that makes sense. So users were effectively cross-compiling the NaCL binaries for multiple architectures.

by xg15

5/20/2026 at 7:04:33 PM

I think the plan was to JIT x86 to other architectures.

by wmf

5/20/2026 at 8:01:14 PM

Heh, emscripten. I remember running the Unreal engine in the browser with that. Quite impressive indeed.

by jorvi

5/20/2026 at 6:17:06 PM

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

by doctorpangloss

5/21/2026 at 8:27:52 PM

While NaCL and Silverlight were both alternatives to Flash...

All these people in comments beating their chests about how WebAssembly is totally good for everything you can imagine, and there's not a single browser game that is not a tic-tac-toe level.

by crabbone

5/20/2026 at 3:18:30 PM

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.

by lmkg

5/20/2026 at 7:51:18 PM

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.

by mccr8

5/20/2026 at 9:33:28 PM

Exactly. "You can't not support it; you can only be slow."

by JoshTriplett

5/20/2026 at 3:46:17 PM

The big difference was that they lacked the market share they enjoy nowadays, with their forks and Electron crap.

by pjmlp

5/21/2026 at 4:35:59 PM

The way I remember it, NaCl and PNaCl ended up nowhere not because big, but because Mozilla, then with big influence on standards, declared them not web enough for the crime of not being JavaScript and pushed against any addition of it into Gecko in any form and promoted "JavaScript is all you need" including an early demo of decoding video in JS - which I recall disgusted me because I somehow knew it would take away various technical issues preventing proprietary encoding from closing down web videos.

Funnily enough, NaCl had its origins in Mozilla extension, with old versions IIRC mentioning lineage starting in Google Gears extension for Firefox

by p_l

5/21/2026 at 1:01:21 AM

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.

by indolering

5/20/2026 at 4:37:09 PM

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)

by benced

5/21/2026 at 12:29:14 AM

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.

by lern_too_spel

5/20/2026 at 2:38:18 PM

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

by rudi-c

5/20/2026 at 5:09:06 PM

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.

by 0x457

5/20/2026 at 6:36:08 PM

Yes, I don't mean that it affects the present. Only sad in a nostalgia sense.

by rudi-c

5/20/2026 at 5:27:07 PM

What’s sad about that is we could have had a clean, native, desktop Figma application.

by frumplestlatz

5/20/2026 at 6:34:37 PM

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.

by rudi-c

5/20/2026 at 7:22:08 PM

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.

by MBCook

5/20/2026 at 7:59:13 PM

How dare you make a performant, accessible app that's easy to distribute, instead of spinning up a different eng. team to maintain a different codebase on a different deployment pipeline so 1% of your userbase can say it's a "real" desktop app instead of a silly "fake" desktop app. :P

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!

by braden-lk

5/21/2026 at 8:06:44 AM

I’m just one data point, but when I tried Figma (admittedly many many years ago), I didn’t find it particularly performant. I remember being intrigued by the concept of vector networks (was that the name?) but being in the browser made it such an awful experience to use and so unreliable to shortcuts that I promptly abandoned it and never looked back.

I never communicated this to the team, but I doubt I was alone. All that is not to knock you down, I just wanted to share that being a proper native desktop app does matter to some people for practical reasons other than performance, even if you’re not aware of it.

by latexr

5/20/2026 at 9:33:56 PM

A native application that further locks users into some single platform? Or accept all the maintenance and development costs and burdens that keep the application one step behind Photoshop if they wanted to support multiple platforms?

by Me1000

5/20/2026 at 9:50:57 PM

They explicitly had the goal of being a web application. It was a product choice, not a technical choice.

by shepherdjerred

5/20/2026 at 2:06:14 PM

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

by futune

5/20/2026 at 2:29:11 PM

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.

by muvlon

5/20/2026 at 4:07:01 PM

Yagrum Bagarn has something for you.

by tadfisher

5/20/2026 at 3:13:40 PM

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.

by mikece

5/20/2026 at 10:48:25 PM

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.

by DarkUranium

5/21/2026 at 1:57:35 AM

Can you talk more? I've seen people say only good things about wasm

by nextaccountic

5/21/2026 at 9:05:04 AM

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.

by avadodin

5/20/2026 at 3:11:48 PM

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

by mikece

5/20/2026 at 3:06:22 PM

Just substitute asm.js with WASM and you're still on the right track.

by phoe-krk

5/20/2026 at 2:30:40 PM

Don't worry, YavaScript will live forever.

by bvisness

5/20/2026 at 4:11:32 PM

In Germany, it's still not uncommon to hear Yava and YavaScript.

by egeozcan

5/20/2026 at 4:18:39 PM

I understand that Jawohl is still quite popular there, but JawohlScript adoption is sadly lagging.

by bonesss

5/20/2026 at 8:30:24 PM

It's the only pronunciation you'll hear in Iceland

by dagurp

5/20/2026 at 3:08:52 PM

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

by mikece

5/20/2026 at 3:35:18 PM

If we substituted war with COVID we aren't that far off as both happened in 2020. We still have to wait till 2035 to see if true.

by ksec

5/20/2026 at 1:58:59 PM

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

by metmac

5/21/2026 at 1:19:56 AM

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.

by ryukoposting

5/20/2026 at 3:14:57 PM

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.

by mikece

5/20/2026 at 4:21:38 PM

wait how did AI impede wasm?

by chamomeal

5/20/2026 at 5:00:43 PM

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.

by xscott

5/21/2026 at 10:59:56 AM

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.

by esperent

5/21/2026 at 8:28:15 AM

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

by veltas

5/20/2026 at 5:02:31 PM

A long time ago, I wrote a small chapter in a WebGL book on asm.js.

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.

by ndesaulniers

5/20/2026 at 2:12:21 PM

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)

by sehugg

5/20/2026 at 2:45:07 PM

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.

by eqrion

5/21/2026 at 6:44:23 AM

In chrome at least asm.js is(/was?) handled by the wasm engine anyway. They essentially did that transpiling at load time.

by Kaxo

5/20/2026 at 1:39:58 PM

Asm.js is dead! Long live WebAssembly!

by drob518

5/20/2026 at 3:06:18 PM

To be fair, I thought asm.js was deprecated a few years ago with emergence of wasm.

by ivanjermakov

5/20/2026 at 7:30:31 PM

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.

by andrewl-hn

5/20/2026 at 2:09:20 PM

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.

by looneysquash

5/20/2026 at 2:32:16 PM

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

by eqrion

5/20/2026 at 2:50:26 PM

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.

by davidmurdoch

5/20/2026 at 3:01:32 PM

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

by flohofwoe

5/20/2026 at 4:32:07 PM

Well, I haven't actually tried the asm.js approach for this, so maybe I'm missing something.

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.

by looneysquash

5/20/2026 at 3:40:51 PM

Oh my God. That's so exciting. I did a prototype a while back for writing UDFs in WASM for a query engine. The fact that everything needed to be copied in and out of the environment killed it. Excited to try it again if/when this lands

by stusmall

5/20/2026 at 3:00:42 PM

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.

by flohofwoe

5/20/2026 at 2:43:01 PM

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.

by chilmers

5/20/2026 at 3:21:02 PM

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

by Rohansi

5/20/2026 at 3:36:28 PM

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

by flohofwoe

5/20/2026 at 5:38:52 PM

I don't think that is true though. The spec make it clear that it only has access to a limited subset of the JS standard libraries and specially registered foreign functions:

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

by chilmers

5/20/2026 at 5:32:59 PM

You can't mix them. It won't pass validation, and will fail to be optimized as asm.js.

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.

by pornel

5/20/2026 at 1:11:46 PM

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

by koolala

5/20/2026 at 4:01:20 PM

The SpiderMonkey team always had t-shirts made up of these.

by dblohm7

5/20/2026 at 1:30:32 PM

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

by stkdump

5/20/2026 at 1:53:11 PM

There's still AssemblyScript? It might meet your requirements, unless I'm misunderstanding you or the features of it.

https://www.assemblyscript.org/

by giancarlostoro

5/20/2026 at 2:09:58 PM

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

by flohofwoe

5/20/2026 at 2:38:14 PM

In fact, I think it was only firefox that made a special JIT route. Chrome moved optimizations into the regular JIT.

by cogman10

5/20/2026 at 2:05:37 PM

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.

by titzer

5/20/2026 at 2:03:42 PM

There are some WAT compilers that are small and fast for running in the browser.

by koolala

5/21/2026 at 6:51:16 AM

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

by richardfey

5/20/2026 at 4:57:19 PM

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?

by hollowturtle

5/20/2026 at 5:21:09 PM

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.

by 0x457

5/20/2026 at 5:01:10 PM

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

by aabhay

5/21/2026 at 2:17:22 AM

There's a real overhead in that wasm can't inline those calls, but Javascript can

by nextaccountic

5/20/2026 at 7:52:18 PM

:(

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.

by trgn

5/20/2026 at 2:38:49 PM

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

by EdwardDiego

5/20/2026 at 7:56:11 PM

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

by karel-3d

5/20/2026 at 4:12:58 PM

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.

by claytongulick

5/20/2026 at 2:07:52 PM

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/

by unconed

5/20/2026 at 5:38:07 PM

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.

by pornel

5/20/2026 at 1:09:20 PM

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

by theultdev

5/20/2026 at 2:40:19 PM

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

by bvisness

5/20/2026 at 1:14:53 PM

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.

by lukan

5/20/2026 at 1:23:47 PM

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.

by theultdev

5/20/2026 at 1:32:04 PM

can we see?

by throawayonthe

5/20/2026 at 1:33:52 PM

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.

by theultdev

5/20/2026 at 2:07:52 PM

It'd be interesting to compare it to a SHA-256 algorithm that uses Wasm simd: https://github.com/ChrisWhealy/wasm_sha256

by titzer

5/20/2026 at 2:09:46 PM

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.

----

https://theultdev.github.io/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.

by theultdev

5/20/2026 at 3:06:47 PM

what's wrong with the built in one?

https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...

by dist-epoch

5/20/2026 at 3:22:35 PM

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.

by wren6991

5/20/2026 at 4:50:11 PM

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.

by theultdev

5/20/2026 at 7:17:34 PM

[dead]

by danborn26

5/20/2026 at 1:20:26 PM

o7

by css_apologist

5/20/2026 at 2:19:51 PM

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

by oneshtein

5/20/2026 at 3:13:50 PM

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

by flohofwoe

5/20/2026 at 2:41:26 PM

Faster in what browser, by what measure, for what modules? "X is faster than Y" without any concretization is usually meaningless.

by mbrock

5/20/2026 at 2:44:50 PM

How can a subset of JS do "everything" that JS can do?

by chilmers

5/20/2026 at 3:00:45 PM

All you need is a lambda

by bogdan

5/20/2026 at 2:35:35 PM

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.

by cogman10

5/20/2026 at 2:49:13 PM

WASM wont improve if no one adopts it. Its a chicken and egg issue

by ramon156

5/20/2026 at 3:14:43 PM

WASM has been adopted and it has improved massively since 2017 though.

by flohofwoe

5/20/2026 at 5:27:49 PM

Yes, but GC is still useless for languages with interior pointers, some features require gimmicks with server configuration, and for most languages we aren't any way closer to -march=wasm and that's all.

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.

by pjmlp

5/20/2026 at 6:16:25 PM

Wasm evolution happens in fits and starts. There's a lot of nested chicken-and-egg problems. We first started on Wasm GC less than two years after MVP, and then we didn't have any language targeting it, so we had to bootstrap it. Now, Java, Dart, Kotlin, and Scala all target Wasm GC (and Virgil too :-)). The interior pointer is on people's radar.

The next big feature coming is stack switching. It works best with unboxed continuations, which necessitates a fat pointer representation in the engine. Once the engine supports fat pointers, then interior pointers will be an easier sell. It might take several years to get there, but Wasm evolves slowly and deliberately, and IMO hasn't made any massive fatal design errors yet.

by titzer