為什麼 WebAssembly 仍不是 Web App 的預設選擇

WebAssembly 是處理熱點效能的工具，不該成為多數 Web App 的預設架構。

我認為 WebAssembly 被過度使用了，對多數 Web App 而言，JavaScript 仍然是第一選擇。2026 年的 Wasm 堆疊確實更成熟，像 WebAssembly 3.0、WasmGC、Component Model 與更好的瀏覽器支援，都讓它在影像處理、AI 推論、遊戲邏輯上有明顯收益。但這些成功案例共同指向同一件事：Wasm 擅長的是狹窄、昂貴、可量測的工作負載，不是廣泛的 UI 應用，把它當預設只會增加複雜度，未必換來等值的速度。

第一個論點

Wasm 的價值是真實的，但它的強項很窄。文章中的 PicShift 影像管線就是好例子：原本在 JavaScript 需要 3 到 4 秒，換成 Wasm 後可壓到 200 毫秒以下。這不是小幅優化，而是體感等級的差距，也證明了 Wasm 最適合的是計算密集、邊界清楚的熱路徑。

同樣的模式也出現在基準測試裡。文章提到 Fibonacci 在 WebAssembly 中可比純 JavaScript 快 3 到 10 倍，並給出一個實務判準：若某段計算在 JavaScript 中超過 5 毫秒，才值得考慮 Wasm。這不是叫你重寫整個前端，而是提醒你把 Wasm 當成選配的加速器，而不是整棟房子的地基。

第二個論點

多數 Web App 的瓶頸根本不在 CPU。真正拖慢產品的，常是 DOM 更新、網路往返、版面重排與狀態管理，而不是某個純計算函式。文章也直接承認，Wasm 不能直接碰 DOM，必須透過 JavaScript glue code 轉接，這讓瀏覽器最核心的互動模型變得更繞、更不直覺。

跨邊界成本也不是抽象問題。文章舉例，將 50 KB 文字傳入 Wasm 函式，序列化就會多出 8 毫秒延遲。這對一般應用邏輯是很重的稅。如果你的功能主要在搬運字串、物件與事件，Wasm 不會簡化系統，只會在原本的瀏覽器執行環境上，再疊一層 runtime 與資料轉換成本。

反方可能怎麼說

最強的反方論點是：Wasm 早已成熟到足以更廣泛採用。WebAssembly 3.0、WasmGC、Component Model 與 WASI Preview 2，確實讓互通性比過去好得多。對想要同一份程式碼同時跑在瀏覽器、伺服器與 edge 的團隊來說，Wasm 的可攜性很有吸引力。

另一個合理主張是產品面需求。對隱私敏感的 AI 推論、離線工具與 edge 工作負載，Wasm 可以降低延遲、減少伺服器成本，也能把資料留在客戶端。文章提到 Cloudflare Workers、Fastly Compute 與瀏覽器內推論，這些都不是邊緣案例，而是已經能創造商業價值的部署方式。

我接受 Wasm 在這些特定工作負載上可以是正解，但這正是它的上限。可攜性不能消除邊界呼叫成本，新標準也不會讓 Wasm 原生理解 DOM。若你的產品成敗取決於 UI 反應速度、整合效率與開發吞吐量，JavaScript 仍是更好的預設；Wasm 應該是針對熱點的優化層，不是整個堆疊的骨架。

你能做什麼

如果你是工程師，先用 JavaScript 做出功能，再用 profiling 找出真正的慢點，只有熱迴圈、編解碼器、模型推論或物理引擎這類區塊才移到 Wasm。若你是 PM 或創辦人，請要求 CPU profile、序列化成本、bundle 體積與維護負擔的證據，再決定要不要導入。Wasm 要在數據逼你選它時才上場，不要因為它聽起來新，就把它變成預設。