讓 WebAssembly 成為 Web 平台的一等公民語言
WebAssembly 在 Web 上仍被視為二等公民，因為它必須依賴 JavaScript 膠水程式碼來進行載入和存取 API，這為開發者帶來了巨大的阻礙。本文探討了隨著語言功能的成熟以及 WebAssembly 元件提案的推動，我們將如何彌補這一差距並簡化開發流程。
背景
WebAssembly（Wasm）自 2017 年發布以來，雖已在高效能運算領域取得進展，但在 Web 開發中仍被視為「二等公民」。Mozilla Hacks 的文章指出，由於缺乏與 Web 平台（如 DOM 和 Web API）的直接整合，開發者必須依賴複雜的 JavaScript 膠水代碼與繁瑣的載入流程，這大幅限制了 Wasm 的普及度。目前社群正致力於透過組件模型（Component Model）與 ESM 整合提案，試圖讓 Wasm 成為 Web 上的原生一等語言。
社群觀點
針對 Wasm 是否能真正成為 Web 一等公民，Hacker News 社群展開了激烈的辯論。支持者認為，目前的開發門檻過高，所謂的「Wasm 懸崖」確實存在，開發者往往在面對複雜的工具鏈與認知負擔時望而卻步。若能實現直接存取 Web API 並消除膠水代碼帶來的效能損耗，將能解鎖更多應用場景，例如讓原生應用的沙盒化插件更易於整合。然而，也有開發者對組件模型的複雜度表示擔憂，認為目前的工具鏈輸出過於混亂，可能只是將複雜性從一處轉移到另一處，而非真正消除問題。
反對意見則從 Web 平台的本質出發，認為 Wasm 在 Web 上註定是二等公民。有觀點指出，JavaScript 的動態特性與物件導向模型與 Web 平台的 DOM 結構完美契合，而 Wasm 的線性記憶體抽象與靜態類型在處理物件導向的 Web API 時存在天然的阻抗失配。即便引入了 GC 支持，也可能因為增加額外開銷而失去 Wasm 原有的效能優勢。這類意見認為，Wasm 雖然在安全性與沙盒化上表現優異，但對於大多數網站而言，JavaScript 已經「足夠好」，且更能適應瀏覽器引擎獨立演進的特性。
此外，社群中也出現了對技術路徑的質疑。部分資深開發者回顧了過去 interface-types 提案的演變，批評開發團隊為了追求跨語言通用性而放棄了更直接的 WebIDL 支持，導致 Wasm 存取 DOM 的進程延宕多年。儘管如此，仍有實務派開發者分享了成功經驗，認為即便沒有組件模型，目前的 Wasm 在跨平台編譯上已經非常成熟，對於遊戲開發或高效能圖形應用而言，調用 JavaScript 的成本在整體運算中幾乎可以忽略不計。這種觀點認為 Wasm 已經是實質上的一等公民，過度工程化地追求 DOM 映射未必能帶來顯著的效能提升。