Firefox 148 開始收掉 asm.js

Firefox 148 預設關閉 asm.js 最佳化，SpiderMonkey 之後會移除相關程式碼，舊專案還能跑，但該轉 WebAssembly 了。

說真的，這不是小改動。Firefox 148 已經把 asm.js 的特殊最佳化關掉了。

Mozilla 的 SpiderMonkey 團隊也講得很直白。這條路會在之後移除。

你可能會想問，asm.js 又不是不能跑了，幹嘛急著收？答案很簡單。因為 WebAssembly 已經接手大部分工作。

Firefox 到底關掉了什麼

先講白了。asm.js 沒有直接消失。它還是 JavaScript 的嚴格子集合，所以舊碼還能照常執行。

真正拿掉的是 SpiderMonkey 那條專門辨識 asm.js 的最佳化路徑。以前引擎會特別對待這種碼，現在不會了。

這差很多。對網站維護者來說，程式還能跑，不代表效能還在。你少了那層特殊處理，速度就回到一般 JavaScript 的 JIT 路徑。

• Firefox 148：asm.js 最佳化預設關閉
• 舊 asm.js 程式：仍可執行
• 特殊編譯管線：後續會移除
• 官方建議：改成 WebAssembly

asm.js 當年為什麼這麼紅

要懂這次調整，得回頭看 2010 年代初期。那時候瀏覽器還不太能扛重型應用。

Mozilla 推 asm.js，是為了讓 C 和 C++ 類型的工作負載，能在瀏覽器裡接近原生速度跑。這在當年很猛，因為它不用額外 runtime。

Mozilla 也不是空口說白話。像 Unity、Unreal Engine 都玩過這條路。EA 的 Epic Citadel 甚至被移到網頁上，而且只花了 4 天。

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

這句話很有意思。asm.js 不是終點，它比較像過橋用的工具。

它證明了一件事。瀏覽器可以承載嚴肅工作負載，不必額外裝一套獨立執行環境。

WebAssembly 為什麼把它擠下去

後來輪到 WebAssembly 上場。這東西的定位更直接，也更乾淨。

Mozilla 說得很明白。asm.js 幫 WebAssembly 開路，而 WebAssembly 在 Firefox 52 就已經進來了。從那時起，舊管線的存在價值就一直在縮。

講白了，維持兩套編譯路徑很傷。工程時間要花，測試要做，安全面也多一塊要顧。當大多數內容都已經搬去 wasm，留著 asm.js 只是在吃維護成本。

• asm.js：Firefox 22 進入
• WebAssembly：Firefox 52 進入
• Firefox 148：asm.js 最佳化關閉
• 後續方向：直接移除 asm.js 程式碼

這對開發者代表什麼

如果你還在用 asm.js，現在該盤點了。Mozilla 已經很清楚地在告訴你，這條路不會再被優先照顧。

最務實的做法，就是重編成 WebAssembly。這不是口號，而是很實際的工程決策。你會拿到更好的執行路徑，也比較容易接上現在的工具鏈。

對產品面來說，這件事也很實在。載入更快，行動裝置壓力更小，弱網路下也比較不痛苦。說真的，現在還死守 asm.js，通常只是技術債越堆越高。

• 舊專案：還能跑，但不再有特殊最佳化
• 新專案：直接選 WebAssembly
• 維護成本：雙管線很難看
• 實務建議：先做轉譯與效能測試

這其實是瀏覽器演進的老故事

很多人看到這種消息，會以為 Mozilla 在砍舊東西。其實不是。這比較像把已經完成任務的零件收起來。

asm.js 的價值，在於它證明瀏覽器能跑重型程式。WebAssembly 接手後，這個任務就不需要兩套解法並存了。

我覺得這件事很合理。平台演進就是這樣，先靠舊方案撐住，再把流量和工具慢慢移到新標準。現在輪到 asm.js 退場，下一個該看的就是你手上的舊建置流程還剩多少包袱。

接下來你該做什麼

如果你的產品還有 asm.js，先別拖。先找出哪些模組還在用，接著評估轉成 WebAssembly 的成本。

如果你已經全站 wasm，那這次變動對你影響不大。你只是少了一個老舊分支要顧。

我會建議團隊現在就排一次檢查。不是因為 Firefox 148 會立刻讓舊碼壞掉，而是因為官方已經開始收尾了。等到真的移除時，才回頭補洞，通常都比較痛。