為什麼 WebAssembly 正在扼殺伺服器端瀏覽器工具

WebAssembly 讓許多瀏覽器工具改在本機執行，速度更快、隱私更好，也不必再靠伺服器上傳與排隊。

我認為，WebAssembly 正在把「上傳到伺服器再處理」這種瀏覽器工具模式擠到邊緣。對於壓縮、加密、解析、轉碼這類單人、檔案導向、可在本機完成的工作，伺服器不再是必要條件。SIMD、執行緒與 GC 支援成熟後，很多原本只能靠後端完成的任務，現在在瀏覽器分頁裡就能跑，而且更快、更私密，也更少摩擦。

第一個論點：性能差距已經縮小到不足以支撐預設走伺服器

過去伺服器端工具的核心理由很簡單：瀏覽器太慢。這個理由現在只對少數極重工作負責。以影像編碼為例，Squoosh 早就證明 AVIF 與 WebP 可以在瀏覽器本機編碼，且體感速度足以取代不少桌面工具。當 SIMD 在 2021 到 2022 年間陸續進入主流瀏覽器後，本機媒體處理不再只是展示技術，而是可以真的交付產品。

執行緒支援把這條線再往前推。ffmpeg.wasm 不是玩具展示，而是多核心可用時，瀏覽器本機轉碼確實能扛起高負載工作的證據。重點不是所有影片流程都該搬進瀏覽器，而是「預設送到後端」已經不再合理。只要任務是有限、可互動、與單一檔案直接相關，瀏覽器現在就是正經的執行環境。

第二個論點：WebAssembly 讓隱私從承諾變成架構結果

伺服器端瀏覽器工具一直靠一種話術撐場：我們不保存檔案、處理完就刪、我們重視隱私。問題是，這些都只是政策，不是結構。WebAssembly 把計算搬到本機後，資料根本不用離開裝置，這是架構帶來的隱私，不是頁尾的一句保證。對使用者與稽核者來說，能檢查程式路徑，比相信刪除政策可靠得多。

hat.sh 很能說明這件事。它透過 Wasm 使用 libsodium，在本機完成加密，避免了這類產品最糟的模式，也就是先叫使用者上傳敏感檔案，再由伺服器「幫忙」。Datasette Lite 與官方 SQLite Wasm 也是同一邏輯：使用者可以在本機查 CSV、跑 SQL、探索資料，而不用把原始資料複本交給遠端後端。這不只是更好的 UX，而是完全不同的安全姿態。

第三個論點：生態已經成熟到足以支撐真正的產品設計

以前大家對瀏覽器本機 Wasm 工具最大的質疑，是啟動成本高、語言支援彆扭。GC 原生支援改變了這件事。當 Chrome 119 與 Firefox 120 提供 GC proposal 後，Python、Kotlin 這類語言不必再背著沉重 runtime 才能在瀏覽器裡正常運作。Pyodide 直接受益，因為它可以把 NumPy 和 pandas 帶進分頁，而不用逼使用者安裝額外環境或申請雲端帳號。

工具鏈的廣度也很關鍵。AudioMass 能在本機做波形編輯與效果處理，代表使用者不必上傳、排隊、等待伺服器渲染。這種模式可以延伸到本機檔案加密、互動式媒體編輯、客戶端資料分析，甚至瀏覽器內資料庫探索。重點不是每個應用都要重寫成 Wasm，而是瀏覽器已經足以承載一大類「免登入、免上傳」工具，且不再脆弱。

反方可能怎麼說

支持伺服器端的人會說，集中式處理比較好維運、比較好更新，也比較容易在單一位置監控與加固。這也是真的。對很多快速迭代團隊來說，把邏輯留在後端，確實能統一格式、控管配額，並讓前端保持簡單。再加上瀏覽器部署有 COOP、COEP 這類條件，執行緒功能並不是零成本。

另一個合理反對點是，並非所有工作都適合留在本機。大型模型、長時間批次任務、多人共享狀態或高度協作流程，仍然更適合伺服器。若任務需要持久化協調與複雜排程，把它放在瀏覽器裡反而是錯的抽象。

但這些反對意見只能劃出邊界，不能保住舊預設。對於單人、檔案導向、重視隱私的工具，伺服器端現在是較弱的選擇，因為它額外增加延遲、帳號門檻與信任成本，卻沒有帶來相稱的價值。WebAssembly 不會取代所有後端，它只是在一大批原本不需要後端的工具上，取代了後端。

你能做什麼

如果你是工程師、PM 或創辦人，先盤點產品裡所有「使用者上傳檔案、等待處理、再下載結果」的流程，這些就是最先該改成 client-side Wasm 的地方。優先挑 CPU-bound、可重現、又牽涉隱私的任務，例如壓縮、加密、解析、過濾與本機分析。只要工具能在分頁裡完整跑完，就把帳號牆拿掉，把 job queue 拿掉，讓隱私保證變成架構事實，而不是行銷文案。