告别 Asm.js
摘要
Mozilla 的 SpiderMonkey 引擎默认禁用 asm.js 优化,标志着这一为 WebAssembly 铺平道路的技术走向终结。建议用户重新编译到 WebAssembly 以获得更好的性能。
暂无内容
查看缓存全文
缓存时间:
2026/05/20 14:27
# 告别 asm.js
来源:https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-asmjs.html
> 斧之时代,剑之时代,盾牌破碎,
> 风之时代,狼之时代,世界倾覆。
> ——《女巫的预言》,诗体埃达(https://sacred-texts.com/neu/poe/poe03.htm)
自 **Firefox 148**(https://www.firefox.com/en-US/firefox/148.0/releasenotes/)起,SpiderMonkey 的 **asm.js**(http://asmjs.org/)优化已被默认禁用,我们计划在未来的版本中彻底移除相关代码。
如果您维护的站点仍在使用 asm.js,请放心,一切不会中断。asm.js 只是普通 JavaScript 的一个子集,因此代码会像其他脚本一样,通过我们的常规 JIT 继续运行。不过,若您将其重新编译为 WebAssembly,将获得更快的执行速度和更小的体积。
## 历史
asm.js(http://asmjs.org/)是 Mozilla 对 **NaCl** 和 **PNaCl**(https://en.wikipedia.org/wiki/Google_Native_Client)所提出的问题的回应:网页如何以原生速度运行代码?
这个想法很巧妙:挑选一个严格的、静态类型的 JavaScript 子集,让引擎能够即时识别并编译为原生代码。这样既能达到接近 NaCl/PNaCl 的性能,又能让代码存活于网页内容之中并使用 Web API(无需单独沙箱、进程间通信或替代 API(https://en.wikipedia.org/wiki/NPAPI#PPAPI))。
asm.js 于 2013 年随 **Firefox 22**(https://blog.mozilla.org/mbest/2013/06/25/asm-js-its-really-fast-backwards-compatible-and-now-in-the-release-version-of-firefox/)发布,并大获成功。它让 Unity 和 Unreal 等项目首次能够仅使用标准 Web 技术将 C/C++ 代码库移植到网页上。**Epic Citadel 演示**(https://blog.mozilla.org/futurereleases/2013/05/02/epic-citadel-demo-shows-the-power-of-the-web-as-a-platform-for-gaming/)仅用四天就移植到了 Web 上。这是一项里程碑式的成就,也是最初的 asm.js 团队的美好回忆。
asm.js 证明了我们可以仅使用 Web 技术在网页上以接近原生的速度运行代码。这为 **WebAssembly**(https://webassembly.org/)打开了大门,后者在几年后随 **Firefox 52**(https://www.firefox.com/en-US/firefox/52.0/releasenotes/)推出。如果没有 asm.js,我们很可能不会有 WebAssembly(https://robert.ocallahan.org/2017/06/webassembly-mozilla-won.html)。
## 为何是现在?
那么为什么要关闭它呢?WebAssembly 已经成功,而 asm.js 的使用已基本迁移过去。保留 asm.js 路径与 WebAssembly 并存,耗费了我们的维护时间,并给虚拟机带来了额外的攻击面。
如果您仍在发布 asm.js 内容,请考虑重新编译为 WebAssembly!我们的 WebAssembly 管道远比曾经的 asm.js 管道先进。您将获得更快的执行速度和更小的体积。
## 诸神黄昏
**OdinMonkey**,由 John Howard 命名
**BaldrMonkey**
asm.js 编译器名为 **OdinMonkey**。正如预言中所说,OdinMonkey 必须面对命定的末日。Bug **Ragnarök**(https://bugzilla.mozilla.org/show_bug.cgi?id=ragnarok)跟踪着“OdinMonkey 的黄昏”。
不过,一切并未失去——从 OdinMonkey 中诞生了 **BaldrMonkey**,我们的 WebAssembly 优化编译器。OdinMonkey 或许会被巨狼芬里尔一口吞下,但 BaldrMonkey 将与 **RabaldrMonkey**(意为“喧嚣”,https://en.wiktionary.org/wiki/rabalder,我们的 WebAssembly 基线编译器)一起,统治重生的世界。
在这个奥丁之日(星期三),我们感谢 OdinMonkey 十三年来的服务。干杯!
> 未耕之田结出成熟果实,
> 一切灾祸化为美好,
> 巴德尔归来;
> 巴德尔与霍德尔同住赫罗普特的殿宇。
> ——《女巫的预言》,诗体埃达(https://sacred-texts.com/neu/poe/poe03.htm)
相似文章
Hacker News Top
Firefox 被编译为在 WebAssembly 中运行,采用基于 WebGL 的渲染和实验性的 JS 到 WASM JIT,网页内容通过 Puter 托管的 Wisp 服务器进行代理。
Lobsters Hottest
本文探讨了 TC39 提出的 ShadowRealm 提案,该提案旨在允许在不使用 iframe 或 Web Workers 的情况下,在隔离环境(Realm)中执行 JavaScript,从而改善代码沙盒机制并提升性能。
Simon Willison's Blog
Puter 将 Firefox 编译为 WebAssembly,使其能够通过使用 Wisp 协议的 WebSocket 代理在另一个浏览器中运行。该演示估计消耗了价值 25,000 美元的 AI 代币,具有端到端加密功能,并提供了公开仓库。
Lobsters Hottest
本文使用 libsodium 加密库对多种 WebAssembly 运行时(WAVM、WasmEdge、WAMR、wasm2c、Wasmer、Wasmtime、Wazero、Node、Bun)进行了性能基准测试,比较了 2024、2025 和 2026 年的版本。结果显示,WAVM、WasmEdge(AOT)、WAMR(AOT)、wasm2c、Wasmer 和 Wasmtime 在 CPU 密集型加密任务中实现了接近原生的性能,而 wide_arithmetic 指令对加密代码有益。
Lobsters Hottest
SpaceWASM 是一个来自 NASA/JPL 的开源 WebAssembly 解释器,专为航天器机载序列化设计,注重确定性内存使用和在资源受限环境下的流式处理能力。