為什麼 WebAssembly 應該維持活標準

WebAssembly 應該維持活標準，而不是凍結成最終 Recommendation。

WebAssembly 應該維持活標準，而不是追求一個看似完整、實則過早的 Recommendation，因為它的價值來自持續把新語意、新驗證規則與新執行能力，快速變成各家引擎都能對齊的共同語言。

證據就在規格本身：WebAssembly Working Group 明確表示核心規格會維持在 Candidate Recommendation 並持續更新，文件也直接提到 version 3.0 與後續增量版本。這不是標準流程失控，而是對一個同時服務瀏覽器、伺服器、嵌入式系統與語言工具鏈的平台，最務實的治理方式。若硬把它推進「已完成」的狀態，反而會把本來就已在實作中的變更，拖進冗長的出版節點。

第一個論點

WebAssembly 的技術面還在快速擴張，根本不適合被當成已經封版的格式。核心規格如今涵蓋 reference types、recursive types、exception handling、vector operations 與 relaxed numeric operations，這些都會改變程式如何表示、驗證與執行。這已經不是早期那種只為 C/C++ 轉譯服務的簡單沙盒，而是一個仍在吸收新能力的運行層。

再看文件結構，規格把 validation、execution、binary format、text format 與 change history 都列成大篇章，這代表標準的工作重點不是「宣告完成」，而是持續校準細節。對這種平台來說，早一步把模糊地帶釐清，往往比等到某個儀式性的最終版更重要。若等 Recommendation 才修正，實作端早就已經面對不一致的語意，代價只會更高。

第二個論點

WebAssembly 的成功，靠的是跨工具鏈、跨引擎的互通，而互通不是一次性達成的成就。規格文件本身就強調 implementation reports、issue tracking 與持續維護的變更紀錄，這說明互通性是一場長期協商，不是一次投票就能結案。活標準把這場協商留在主文件裡，讓規格更接近真實世界，而不是把問題丟到零散的 errata 或各家部落格公告。

部署面也支持這個判斷。WebAssembly 不只跑在瀏覽器，文件還明說它可以嵌入 standalone VM，並整合到其他環境。這意味著瀏覽器、伺服器、edge 與嵌入式平台不會同步升級，也不會在同一天需要同一組特性。持續更新的核心規格，能提供共同目標，讓各家實作按自己的節奏落地；若把標準凍住，並不會消除分歧，只會讓分歧更難對齊。

反方可能怎麼說

支持 Recommendation status 的人，最強的理由是制度信任。最終標準能向保守採購方傳遞穩定訊號，也能把「已定稿」與「仍在演進」切開，讓企業更容易做風險控管。對一些技術來說，這種清楚的終點線確實有助於收斂爭議，避免標準長期停在半成品狀態。

這個論點不是錯的，但它不適合 WebAssembly。因為 WebAssembly 的核心已經是多個高階特性與相關規格的底座，而文件也承認部分內容仍在演進。若硬把核心凍成最終版，結果不會是安定，而是規格文字與實作現況脫節。真正該守住的界線，不是「永遠不要穩定」，而是「在互通性要求穩定的地方穩定，在其餘部分保留持續發布的彈性」。WebAssembly 需要的是穩定契約，不是靜態檔案。

你能做什麼

如果你是工程師，請把活標準當成訊號：要讀最新規格，不要只靠舊文章或口耳相傳；要看 implementation report、追 issue tracker，並在多個引擎上測試。如果你是 PM 或創辦人，產品路線圖應該跟著規格演進，而不是等某個最終蓋章才啟動。最好的做法，是先對齊當前已互通的子集合，再隨標準與實作收斂逐步擴展。對 WebAssembly 來說，速度來自持續標準化，不來自假裝平台已經完成。