SpiderMonkey is retiring asm.js in Firefox 148

Firefox 148 disables asm.js optimizations by default, and SpiderMonkey will remove the code later.

Mozilla’s SpiderMonkey team says the browser’s asm.js path is now off by default in Firefox 148, and the engine will drop the code in a future release. That matters because asm.js once helped web apps run near native speed, but the same workloads have largely moved to WebAssembly.

What Mozilla is turning off

asm.js is not disappearing from the web overnight. It is a strict subset of JavaScript, so code that depends on it still runs through SpiderMonkey’s normal JIT path. What is going away is the special optimization pipeline that used to detect asm.js and compile it differently.

That distinction matters for site owners. If you have old asm.js code, Firefox will still execute it. You just lose the extra engine work that once made it faster. Mozilla is making a practical cleanup call here: keep supporting the old path, or remove a code path that now duplicates work WebAssembly already handles better.

• asm.js optimizations: disabled by default in Firefox 148
• asm.js code execution: still works as plain JavaScript
• Future plan: remove the dedicated asm.js code entirely
• Recommended migration target: WebAssembly

Why asm.js mattered in the first place

To understand this move, you have to remember what web performance looked like in the early 2010s. Mozilla built asm.js as a response to NaCl and PNaCl, both of which tried to answer a simple question: how can the web run code at native speed?

asm.js took a strict, statically typed slice of JavaScript and let the engine recognize it quickly. That let developers ship heavy C and C++ applications without leaving the browser. Unity and Unreal Engine both used it, and Mozilla says the Epic Citadel demo moved to the web in just four days.

“asm.js shipped in Firefox 22 back in 2013 and was a success.” — Ryan Hunt, SpiderMonkey

That quote gets at the real story. asm.js was never the end goal; it was the bridge. It proved that browsers could execute serious workloads with web technologies alone, without a separate runtime, IPC layer, or a special API surface.

How WebAssembly changed the equation

WebAssembly arrived later and took the same basic promise much further. Mozilla says asm.js opened the door to WebAssembly, which shipped in Firefox 52. Once wasm became the standard path for compiled code on the web, the old asm.js compiler started to look like maintenance debt.

SpiderMonkey is also being blunt about the tradeoff. Keeping the asm.js path alive costs engineering time and adds attack surface inside the VM. If most real-world asm.js content has already migrated, the browser gets little back from preserving a second specialized compiler.

• asm.js in Firefox: shipped with Firefox 22
• WebAssembly in Firefox: shipped with Firefox 52
• Firefox 148: asm.js optimizations off by default
• SpiderMonkey’s recommendation: recompile to WebAssembly

What developers should do next

If you still ship asm.js, Mozilla’s advice is simple: move to WebAssembly. The team says the wasm pipeline is more advanced than the asm.js pipeline ever was, and the payoff is practical rather than theoretical. You should get faster execution and smaller binaries.

That last part matters for real products. Faster startup helps on mobile, smaller payloads help on slow connections, and wasm tooling has matured enough that keeping legacy asm.js around usually makes less sense than porting. If you are maintaining a codebase built for the old pipeline, this is a good moment to measure the cost of staying put.

For teams already on WebAssembly, this is mostly a cleanup story. For teams still on asm.js, it is a warning that the browser is no longer investing in that path. The code still runs, but the special treatment is gone, and the removal clock has already started.

Mozilla is closing one chapter and keeping the lesson

SpiderMonkey is retiring asm.js because WebAssembly won, not because the old idea failed. asm.js proved that the browser could host serious compiled workloads, and that proof helped make wasm possible.

The practical question now is simple: if your app still depends on asm.js, how long do you want to wait before recompiling? Mozilla has already answered on its side, and Firefox 148 makes that answer visible to everyone using the browser today.