2023 年度 WebAssembly 現狀調查結果出爐，下面就來看看 2023 年的 WebAssembly 發展的怎么樣了！

WebAssembly 是一種可移植、低級別的字節碼語言，旨在提供一種通用的編譯目標，以允許在 Web 上執行高性能計算密集型應用程序。它是一種新型的虛擬機技術，可以在所有主要的 Web 瀏覽器中運行，并且還可以在其他環境中使用。

WebAssembly 通過在 Web 瀏覽器中嵌入本地代碼模塊，能夠直接訪問底層系統硬件，實現了快速加載和執行的特性，因此被廣泛認為是未來 Web 應用的基礎技術之一。WebAssembly 可以與 JavaScript 和其他 Web 技術協同工作，使開發人員能夠使用多種編程語言來構建在線應用，并且具備高效、跨平臺的特點。

WebAssembly 于 2019 年 12 月 5 日成為萬維網聯盟（W3C）的推薦標準，與 HTML，CSS 和 JavaScript 一起成為 Web 的第四種語言。

下面是本次調查結果概覽：

• Rust 和 JavaScript 的使用量持續增加，但一些更顯著的變化：Swift 和 Zig 的采用率都顯著增加。
• 當談到開發者所“渴望使用”的編程語言時，Zig、Kotlin和C#等語言的受歡迎程度超過了它們目前的實際使用率。
• WebAssembly 仍然最常用于 Web 應用開發，但 Serverless 正在持續興起，使用 WebAssembly 作為插件環境的使用也在增加。
• 線程、垃圾回收和相對較新的組件模型提案是人們最感興趣的 WebAssembly 發展方向。
• 對于 WASI（WebAssembly 系統接口），最受關注的是 I/O 提案（如 HTTP、文件系統）。
• 開發者對 WAI 發展的滿意度明顯低于對 WebAssembly 發展的滿意度。
• 開發者希望 WebAssembly 能夠兌現 Java 最初做出的“一次編寫，到處運行”的承諾。

語言

在開發時利用 WebAssembly 的應用時使用或嘗試過使用的語言統計如下：

Rust 連續第三年成為 WebAssembly 最常用的語言。Rust 一直非常適合 WebAssembly；它是一種廣泛流行的現代系統級語言（Stack Overflow 連續七年顯示它是最受歡迎的語言），它也恰好是一種用于編寫 WebAssembly 運行時和平臺的流行語言。

JavaScript 是第二廣泛使用的編程語言。盡管無法直接將 JavaScript 編譯為 WebAssembly，但可以通過將 JavaScript 代碼運行時編譯為 WebAssembly 來實現在 WebAssembly 中執行 JavaScript 代碼的方式。在這種方法中，代碼將在 WebAssembly 托管的解釋器中運行。盡管可能會犧牲一些性能，但出人意料地實用，并且越來越受歡迎。雖然可能無法從速度上獲得優勢，但確實可以受益于 WebAssembly 的安全性和隔離性。

下圖顯示了長期趨勢，將最近三次調查的結果進行比較，列出了每種語言的使用百分比（經常或偶爾使用），排除使用率低于10％的語言。

Rust 和 JavaScript 的使用率正在增加，但還有一些更顯著的變化：Swift 和 Zig 的采用率均顯著增加。

Swift 是 WebAssembly 生態系統中相對較新的成員，始于幾年前對 Apple Swift 存儲庫的拉取請求以添加 wasm 目標。然而，盡管多年來進行了多次提交，但該 PR 尚未合并。

雖然Swift和Rust都是相對較新的語言（分別于2014年和2015年誕生），但Zig則更為年輕，于2016年出現，比WebAssembly（WebAssembly于2017年發布了第一個MVP版本）早一年。

今年，我們在調查中添加了一個新問題，旨在了解與 WebAssembly 相關的專業關系。我們的目標是將積極開發 WebAssembly 工具或平臺的人員與最終用戶的響應分開。通過將這兩組分離，可以看到以下語言的偏好情況：

正如預期的那樣，工具開發人員對 Rust 有著強烈的偏好，并且也喜歡直接使用 WAT（WebAssembly 文本格式）對 WebAssembly 進行編程。開發者對 Go 和 Python 也有強烈的偏好。

對于問題“未來想使用哪些語言來開發利用WebAssembly的應用”，統計結果如下：

Rust 再次名列前茅，反映了年度 Stack Overflow 調查的結果，其次是JavaScript。然而，使用頻率較低的 Zig 是第三個最受歡迎的語言。

通過繪制每種語言的差異，即“經常使用”的回答數量和“希望大量使用”的回答數量之間的差距，可以看出在受歡迎程度與使用率之間有著最大差異的語言：

可以看到，Zig、Kotlin 和 C# 的受歡迎程度超過了當前的使用率，C++、JavaScript 和 WAT 的當前的使用率超過了受歡迎程度。

運行時

考慮到WebAssembly在非瀏覽器環境下的使用正在增加，探索正在使用哪些運行時或者僅僅是聽說過哪些運行時很有意思。這次調查只問了一個問題：“你聽說過或使用過哪些運行時？結果如下：

wasmtime，來自于字節碼聯盟（Bytecode Alliance），是最廣泛使用的運行時，而由一家初創公司開發的 wasmer 排名第二。Wazero 是一個新成員，它是一個基于 Go 語言構建的最近發布的運行時。

實際應用

使用 WebAssembly 的目的如下：

Web 應用開發仍然處于領先地位，但差距正在縮小。下圖顯示了同比趨勢：

Serverless 正在持續增長，但可能最引人注目的轉變是WebAssembly作為插件環境的使用。以下是一些實際應用的例子：

• Zellij是一個面向開發者的終端工作空間，它采用了WebAssembly插件模型。
• Microsoft Flight Simulator 允許將附加組件編寫為 wasm 模塊。
• Envoy 和 Istio 有一個 Wasm Plugin API。
• Lapce，一個用 Rust 編寫的新 IDE，有一個基于 WASI 的插件系統。

在每種情況下，平臺（終端、編輯器、代理）都從允許最終用戶使用多種編程語言擴展功能的能力中受益，并且這些功能在一個安全而隔離的環境中運行。換句話說，如果有人編寫了一個行為不端或性能較差的插件，對平臺本身的影響將被最小化。

受訪者所在組織采用 WebAssembly 的狀況如下：

從上圖中可以看到，41% 的受訪者正在生產中使用 WebAssembly，還有 28% 的受訪者正在試點或計劃在明年使用它。

該調查還探討了 WebAssembly 需要什么來幫助推動進一步采用：

被最頻繁提及的需求是通過 WASI（WebAssembly系統接口）來改善非瀏覽器集成。WebAssembly 規范并未定義任何主機集成點，無論是如何訪問 DOM 還是與主機運行時交換數據（例如在瀏覽器中將值傳遞給 JavaScript）。WASI正填補這一空白，但目前還沒有完整的解決方案。

更好的調試支持緊隨其后，隨著人們使用 WebAssembly 開發越來越復雜的解決方案，這一點將變得更加重要。

特性

WebAssembly（由W3C管理）和WASI（由W3C WebAssembly社區組的子機構管理）都在不斷發展，有一系列新功能遵循標準的5階段提案過程。

關于 WebAssembly 提案，以下是最需要的：

線程、垃圾收集和異常處理在去年的結果中均名列前茅，并且這三者都處于提案生命周期的實施（第 3 階段）或標準化（第 4 階段）。這意味著它們已準備好使用，并且接近完成。

組件模型是一個處于早期階段的提案（第 1 階段），其目標是使在運行時以任何語言編寫的 wasm 模塊變得更加容易。

關于 WASI 提案，以下是最需要的：

四個最重要的提案都與 I/O 相關，可見，創建 WebAssembly 模塊與外界通信的標準方式是當務之急。

受訪者對 WebAssembly 和 WASI 的發展的滿意度如下：

有很多人對這個情況表示不滿意，這一點并不令人意外，以開放透明的方式演化的規范，涉及很多利益相關者，并不容易，并且需要時間。

不過，這個結果不應被用作直接批評 WASI 和 WebAssembly 團隊所做出的出色努力。人們對 WASI 演進的不滿可能只是對這項技術熱情的反映，這并不是一件壞事。

小結

最后，來總結一下受訪者對 WebAssembly 最興奮的點：

• 可移植性和在不同平臺上運行代碼的能力。
• 不同語言和Web之間的互操作性。
• 本地性能和效率。
• 訪問現有代碼和庫的能力。
• 新語言和工具的潛力。
• 安全性和沙箱功能。
• 替代容器并在瀏覽器中運行復雜堆棧的能力。
• 通用二進制格式的潛力。
• 編寫一次，在任何地方運行的機會。
• 提高性能和速度。
• 組件模型和代碼重用的能力。
• 減少或消除對JavaScript的依賴。
• 在語言選擇上更靈活、多樣化的選擇。
• 插件系統的潛力。
• 在瀏覽器中運行復雜應用程序的潛力。