Wasm 原生時代已經來到

Ending 定律：一切可編譯為 WebAssembly 的，終將被編譯為 WebAssembly（Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually）。

PART. 0

前言

WebAssembly 作為一種新興的網頁虛擬機器標準，它的設計目標包括：高可移植性、高安全性、高效率。

2018 年 WebAssembly 第一個規範草案誕生，2019 年成為 W3C 第四個標準語言。到了 2022 年底可以說我們已經進入了 Wasm 原生時代……

PART. 1

Ending 定律和 Wasm 原生

1、什麼是 Ending 定律

Ending’s law: “Any application that can be compiled to WebAssembly, will be compiled to WebAssembly eventually.”

Ending 定律：“一切可編譯為 WebAssembly 的，終將被編譯為 WebAssembly。”

Ending 定律也稱為終結者定律，它是 Ending 在 2016 年 Emscripten 技術交流會上針對 WebAssembly 技術給出的斷言。Ending 定律的威力不僅僅在語言層面。WebAssembly 是第一個虛擬機器世界標準，以後將人手至少一個 Wasm 虛擬機器。

不過和之前被大家鄙視的 JavaScript 語言大舉入侵各個領域的情況不同，這次 Python、Ruby 這些語言將徹底擁抱 WebAssembly 技術，因為它是一個更底層、也更加開放的新興生態平臺。從 Ending 定律可以預測 Wasm 原生時代遲早都會到來。

2、什麼是 Wasm 原生

Wasm 原生可以類比雲原生的定義：就是天生就是為 WebAssembly 平臺設計的程式和語言。比如專門為 WebAssembly 設計的 AssemblyScript 語言和凹語言就是 Wasm 原生的程式語言。如果一個應用天生就是考慮了 WebAssembly 的生態支援，那麼就是 Wasm 原生的應用。一個 Wasm 原生應用很容易支援純瀏覽器環境，因此不支援純瀏覽器環境的應用大機率不是 Wasm 原生。

現在 Docker 已經開始支援 Wasm 程式，因此 Wasm 原生軟體天然也是雲原生的軟體，但是反之則不能成立。而云原生因為受限於雲的環境、導致其應用的場景和領域有較大的限制，比如雲原生應用強依賴網路因此無法在很多微控制器環境、甚至是本地環境執行，因此雲原生更多是在網際網路企業流行。但是 Wasm 原生的程式則可以輕鬆在 Arduino 等受限環境、本地桌上型電腦機環境、個人智慧手機環境和 Kubernetes 等雲原生環境執行。可以說未來 Wasm 原生應用將無處不在！

PART. 2

WebAssembly 簡史

WebAssembly (簡稱 Wasm) 是 W3C 定義的第 4 個標準，是 Web 的第 4 種語言。說 WebAssembly 是一門程式語言，但實際上它更像一個編譯器，其實它是一個虛擬機器，它還包含了一門低階組合語言和對應的虛擬機器體系結構，而 WebAssembly 這個名字從字面理解就說明了一切：“Web 的組合語言”。

簡而言之，WebAssembly 是一種新興的網頁虛擬機器標準，它的設計目標包括：高可移植性、高安全性、高效率（包括載入效率和執行效率）、儘可能小的程式體積。

1、Emscripten 專案

WebAssembly 的前身是 Mozilla 建立的 Emscripten 專案(2010年)——透過將 C/C++ 透過 LLVM 編譯到 JavaScript 的 asm.js 子集來提速！JavaScript 作為弱型別語言，由於其變數型別不固定，使用變數前需要先判斷其型別，這樣無疑增加了運算的複雜度、降低了執行效能。因為 asm.js 僅包含可以預判變數型別的數值運算，有效的避免了 JavaScript 弱型別變數語法帶來的執行效能低下的頑痾。根據測試，針對 asm.js 最佳化的引擎執行速度和 C/C++ 原生應用在一個數量級。

2015 年 6 月 Mozilla 在 asm.js 的基礎上釋出 WebAssembly 專案，隨後 Google、Microsoft、Apple 等各大主流的瀏覽器廠商均大力支援。WebAssembly 不僅擁有比 asm.js 更高的執行效能，由於使用了二進位制編碼等一系列技術，WebAssembly 編寫的模組有更小的體積和更高的解析速度。目前不僅 C/C++ 語言編寫的程式可以編譯為 WebAssembly 模組，Go、Kotlin、Rust、Python、Ruby、Node.js、AssemblyScript、凹語言等新興的程式語言都開始對 WebAssembly 提供支援。

2、 WebAssembly 1.0 草案

WebAssembly 技術自誕生之日就進入高速發展階段。在 2018 年 7 月 WebAssembly 1.0 草案正式釋出，在 2019 年 12 月正式成為 W3C 國際標準，成為與 HTML、CSS 和 JavaScript 並列的唯四前端技術。2019 年，同樣誕生了 Wasi (WebAssembly System Interaface）規範，用於將基本的系統呼叫帶入到 Wasm 生態。2022 年 Docker 對 Wasm 提供支援，目前 WebAssembly 已經是一個獨立的生態。

3、 WebAssembly 生態大圖

下面是 “WebAssembly 將引領下一代計算正規化” 展示的生態大圖：

可以看到從工具鏈、基礎設施、到應有和 Web3 均有涉及，生態已經非常豐富。正和 JVM 構建的生態類似，WebAssembly 也在構建自己的龐大生態。

PART. 3

Wasm 社群 22 年的變化

2022 年，國內外自媒體社群對 WebAssembly 的評價態度可謂是完美遵循了欲揚先抑的劇本。

先是有熱文爆大佬 WebAssembly 創業失敗引發質疑，然後是傳出社群分裂、應用爭議再引發炒錯的方向等爭論，然後隨著 Docker 對 Wasm 支援的預覽版釋出帶來風向 180 度大轉彎，簡直是要把不明真相的群眾徹底忽悠拐了。其實 WebAssembly 從誕生之日起，真正的從業人員始終在穩步推進，完全沒有自媒體想象和策劃的這些劇本演義。

1、WebAssembly 2.0 草案

4 月 20 日，W3C 公佈了 WebAssembly 2.0 的第一批公共工作草案。主要包含向量型別、引用型別、多返回值、多 Table 支援、Table 和記憶體指令增強等。

向量型別的支援可以用於最佳化純計算型別的併發程式、引用型別可以用於和外部的瀏覽器 DOM 物件等更好的互動、多返回值可以可以簡化某些程式的表示（比如凹語言後端依賴該特性）、多 Table 支援可能用於靈活支援多模組連線等。可以說 WebAssembly 標準是該生態的統一基準平面，而且這些特性的實現已經相對普及，可以作為實驗特性試試用。

比如凹語言後端依賴該特性）、多 Table 支援可能用於靈活支援多模組連線等。可以說 WebAssembly 標準是該生態的統一基準平面，而且這些特性的實現已經相對普及，可以作為實驗特性試試用。

完整文件參考：https://www.w3.org/TR/wasm-core-2/

2、Docker 支援 WebAssembly

2019 年，Docker 創始人 Solomon Hykes 釋出了一條推文，他說如果 2008 年就誕生 WebAssembly 和 Wasi 的話，Docker 就沒有必要誕生了。

其實作者在 2018 年寫作《WebAssembly 標準入門》時， 透過推演也得出過類似的結論：當時的結論是 WebAssembly 更大的生命力在瀏覽器之外，如果配合檔案系統、網路系統將得到一個更為迷你的作業系統無關的執行平臺。

Docker 與 WasmEdge 合作建立了一個 containerd shim，該執行時支援執行 Wasm 程式。下面是 Docker 對 Wasm 的支援原理圖：

Docker 執行 Wasm 需要指定一些額外引數：

$ docker run -dp 8080:8080 \    
--name=wasm-example \    
--runtime=io.containerd.wasmedge.v1 \
--platform=wasi/wasm32 \
michaelirwin244/wasm-example

首先 runtime 引數指定 Wasmedge 執行時，然後 platform 指定採用 Wasi/wasm32 規範（指定有哪些宿主 API）。

完整的資訊可以參考 Docker 的官方文件：https://docs.docker.com/desktop/wasm/

3、SQLite3 官方支援 WebAssembly

SQLite3 作為一個純粹的 C 語言庫，其實在 WebAssembly 標準誕生之前就可以透過 Emscripten 技術將 C 程式碼編譯為 asm.js。

因此，網上很早就有在瀏覽器的 JS 版本、甚至直接透過 Emscripten 輸出 WebAssembly。不過這次是 SQLite3 官方提供了對 WebAssembly 的支援，這表示 WebAssembly 在 SQLite 社群完全進入工業級應用階段！

根據官網介紹，主要有 4 個目標：

• 繫結一個低階的 SQLite3 API，在使用方面儘可能接近原生 API；
• 更高階別的物件導向風格 API，類似於 sql.js 和 node.js 樣式的實現；
• 基於 Worker 的 API，以支援多執行緒環境更容易使用 SQLite 功能；
• 基於 Worker API 的 Promise 包裝，對使用者完全隱藏了跨執行緒通訊方面複雜性。

而不在此列的特性包括不支援 UTF 16、和清除老舊特性等。簡而言之，在提供底層 API 能力的同時，針對物件導向、多執行緒等環節提供簡單易用的 API。

完整的介紹請參考：https://sqlite.org/wasm

4、Ruby 3.2 支援 WebAssembly

12 月釋出的 Ruby 3.2 也增加了基於 Wasi 的 WebAssembly 支援。使得 CRuby 二進位制內容可用於瀏覽器、Serverless Edge、以及其他 WebAssembly/Wasi 嵌入環境。

目前，此功能已透過除 Thread API 之外的 basic 和 bootstrap 測試套件。

雖然目前基於安全原因，還缺少一些功能來實現纖程、異常和垃圾回收的特性，但是這已經讓使用者可以在瀏覽器中嘗試原生的 CRuby：https://try.ruby-lang.org/playground/

5、Python 3.11 支援 WebAssembly

和 Ruby 社群的目標類似，Python 社群也在 4 月啟動在 Python 3.11 增加對 WebAssembly 的支援。Python 3.11 對 wasm32-emscripten 和 wasm32-wasi 提供了支援，從而也實現了在瀏覽器執行 Python 的夢想。

具體細節可參考以下文件：

• https://pythondev.readthedocs.io/wasm.html
• https://docs.python.org/3/library/intro.html#webassembly-plat...
• https://speakerdeck.com/tiran/python-3-dot-11-in-the-web-brow...

因為有了 WebAssembly 魔法加持，Ruby 和 Python 等指令碼語言也終於可以在瀏覽器玩耍了。

6、為 WebAssembly 而生的凹語言

WebAssembly 草案剛剛釋出不久，國外就誕生了專門為其設計的 AssemblyScript 語言。

在 2022 年 7 月，國內 Gopher 也發起了針對 WebAssembly 平臺的凹語言。目前凹語言不僅僅提供了線上的 Playground，還上線了用凹語言開發的貪吃蛇小遊戲。希望新興的語言可以為 WebAssembly 注入更多的活力。

▪凹語言主頁：https://wa-lang.org/

▪凹語言倉庫：https://github.com/wa-lang/wa

▪凹語言開發的貪吃蛇：https://wa-lang.org/wa/snake/

PART.4

Wasm 虛擬機器實現

對於 JavaScript 使用者，直接透過瀏覽器內建的 WebAssembly 模組即可，或者是透過 Node.js 提供的模組 API。我們這裡簡要介紹的是瀏覽器環境之外的 Wasm 虛擬機器實現，這裡介紹的主要有 C/C++、Rust 和 Go 語言幾類實現。

總體來說，大家完全不需要擔心 Wasm 虛擬機器的選擇和切換代價，只要遵循 Wasm 標準原則切換虛擬機器就和換個滑鼠一樣容易。

1、C/C++ 語言｜WasmEdge、wasm3 和 Wamr

WasmEdge 和 Wasm3 是 C/C++ 語言實現的具有代表性的兩個 WebAssembly 虛擬機器（沒有包含 V8 的虛擬機器）。

WasmEdge 可以說是目前最受關注的 WebAssembly 虛擬機器實現，因為它不僅僅是 CNCF 推薦的 Wasm 虛擬機器，更是 Docker 內建的 WebAssembly 虛擬機器。WasmEdge 是由美國的袁鈞濤（Michael Juntao Yuan）發起，是由 CNCF 託管的雲原生 WebAssembly runtime。

它廣泛應用於邊緣計算、汽車、Jamstack、Serverless、SaaS、服務網格，乃至區塊鏈應用。WasmEdge 可以進行 AOT（提前編譯）編譯器最佳化，是當今市場上最快的 WebAssembly runtime 之一。

可以預計，隨著 Docker Wasm 的普及，WasmEdge 將成為最流行的 Wasm 虛擬機器實現之一。

WasmEdge：https://wasmedge.org

袁鈞濤 (Michael Juntao Yuan)：https://github.com/juntao

Wasm3 是 C 實現的 WebAssembly 引擎，可執行在嵌入式裝置上。因為需要的資源比較少，目前可以執行在 Arduino 和樹莓派環境。

Wasm3 倉庫：https://github.com/wasm3/wasm3

由 Mozilla、英特爾、RedHat 和 Fastly 公司宣佈成立位元組碼聯盟（Bytecode Alliance）開發的 WebAssembly Micro Runtime（Wamr）也是一個非常優秀的虛擬機器實現，其提供 AOT、JIT 等多種不同的最佳化手段，底層也是依賴 LLVM 後端的一些能力。

▪Wamr 的倉庫：https://github.com/bytecodealliance/wa sm-micro-runtime

2、Rust 語言｜Wasmer 和 Wasmtime

Wasmer 和 Wasmtime 是 Rust 實現的兩個流行的 WebAssembly 虛擬機器。根據 2022 年 7 月的調查報告 (300人提交問卷) 顯示，來自位元組碼聯盟的 Wasmtime 最流行、其次為 Wasmer。不過從長期看，作者推測 WasmEdge 將隨著 Docker/wasm 成為瀏覽器外最流行的 Wasm 虛擬機器實現。

▪Wasmtime 倉庫：https://github.com/bytecodealliance/wasmtime
▪Wasmer 倉庫：https://github.com/wasmerio

3、Go 語言｜WaZero

WaZero 是純 Go 語言實現的 WebAssembly 虛擬機器，因此不需要依賴 CGo 特性。目前凹語言內建的就是 WaZero 虛擬機器。

倉庫地址：https://github.com/tetratelabs/wazero

另外，國內張秀宏著的《WebAssembly 原理與核心技術》討論了用 Go 語言如何實現 WebAssembly 虛擬機器，感興趣的讀者可以參考。

PART.5

支援 Wasm 的程式語言

WebAssembly 允許開發者用幾十種程式語言（包括 AssemblyScript、C/C++、Rust、Golang、JavaScript 和凹語言等）編寫應用程式。

支援 Wasm 的程式語言主要分為 3 類：

1. 首先是專門為 WebAssembly 設計的新語言，比如 AssemblyScript 和凹語言等；
2. 其次是將語言編譯到 WebAssembly 目標平臺，比如 C/C++、Rust、Golang 這類語言（和第一類有一定重疊）；
3. 最後是將語言的虛擬機器或直譯器編譯到 WebAssembly 平臺，比如 Lua、JavaScript、Ruby 和 Python 這些。

除此之外，還有一些其它的領域語言也在支援 WebAssembly 平臺。

支援 WebAssembly 的語言列表：https://github.com/appcypher/awesome-wasm-langs

1、JavaScript｜WebAssembly 替換的標

JavaScript 開始其實是 WebAssembly 要替換的目標。但是隨著 WasmEdge 等引擎支援 QuickJS 的直譯器，JavaScript 逐漸變成了 WebAssembly 平臺之上的最流行的程式語言。這裡除了有 JavaScript 語言使用者比較多的因素，同時 JavaScript 的單執行緒模型也非常契合 WebAssembly 的單執行緒模型（只是相對於 Python 等支援多執行緒的指令碼語言，套娃的效能損失至少 10 倍起）。

JavaScript 和 WebAssembly 無限套娃的事情真在切實發生，同時 JavaScript 也失去了瀏覽器中的霸主地位，降級為普通公民。

2、AssmblyScript｜為 WebAssembly 而生的 TypeScript

AssemblyScript 是一個把 TypeScript 語法搬到 WebAssembly 的編譯器。它目前是 WebAssembly 環境非常受歡迎的一個語言。

AssemblyScript 只允許 TypeScript 的有限功能子集，因此不需要花太多時間就可以上手。同時它與 JavaScript 非常相似，所以 AssemblyScript 使 Web 開發人員可以輕鬆地將 WebAssembly 整合到他們的網站中，而不必使用完全不同的語言。

下面是一個 AssemblyScript 程式，和 TypeScript 幾乎是一樣的：

export function add(a:i32, b:i32):
return a + b;
}

不過 AssemblyScript 只有 WebAssembly 支援的基本型別，而複雜的型別透過內建庫實現。同時為了提供靈活的擴充套件能力，AssemblyScript 編譯器提供了擴充套件能力。

AssemblyScript 主頁：https://www.assemblyscript.org/

3、C/C++｜WebAssembly 為其而生

C/C++ 是 WebAssembly 該技術前身 Emscripten 誕生時的初始目標。Emscripten 專案，嘗試透過 LLVM 工具鏈將 C/C++ 語言編寫的程式轉譯為 JavaScript 程式碼，在此過程中建立了 JavaScript 子集 asm.js，asm.js 僅包含可以預判變數型別的數值運算，有效的避免了 JavaScript 弱型別變數語法帶來的執行效能低下的頑痾。

其中的核心魔法使 WebAssembly 和 C/C++ 採用相似的線性記憶體模型，提供為 JIT 提供了轉化為相似程式碼的可能。

4、Rust 語言｜基於 LLVM 的輸出 WebAssembly 能力

Rust 和 Emscripten 都誕生於 Mozilla 公司，因此目前 WebAssembly 社群和 Rust 社群有著很大的重疊部分。很多 Rust 實現的 WebAssembly 虛擬機器，同時 Rust 編譯器藉助 LLVM 的能力輸出 WebAssembly 模組。

可以說 Rust 技術的發展和抱住 WebAssembly 這個大腿有極大的關係。當然，因為 Rust 相容 C/C++ 記憶體模型同時又無 GC 依賴，使得 Rust 可以構造出非常輕量高效的 Wasm 模組。不過 Rust 本身的超高門檻也為初學者帶來了極大的挑戰。

5、Go 語言｜獨立的 WebAssembly 後端

Go 語言作為雲端計算等領域的主流語言，從 Go1.11 開始，WebAssembly 開始作為一個標準平臺被官方支援，這說明了 Go 語言官方團隊也認可了 WebAssembly 平臺的重要性和巨大潛力。

目前 Go 語言社群已經有眾多與 WebAssembly 相關的開源專案，比如有很多開源的 WebAssembly 虛擬機器就是採用 Go 語言實現的。不過 Go 語言對 WebAssembly 被詬病的一個方面是官方生成的 Wasm 檔案不是 wasi 規範，同時因為 GC 等特性導致 Wasm 體積比較大。

社群有個針對嵌入式環境等 TinyGo 變種，後端同樣藉助 LLVM 的能力輸出 WebAssembly 模組。不過因為 LLVM 的依賴非常重，導致 TinyGo 的單個命令列將近 100MB、同樣的原因導致無法方便在瀏覽器環境使用。可以說 TinyGo 本身並不 Tiny，只是其目標平臺是針對 Tiny 的微控制器和 Wasm 等平臺。

6、凹語言｜為 WebAssembly 而生的國產語言

凹語言是為 WebAssembly 而設計的新語言，是國內 Gopher 發起的純社群構建的開源國產程式語言專案。

同時凹語言也是國內第一個實現純瀏覽器內編譯、執行全鏈路的自研靜態型別的編譯型通用程式語言。凹語言不僅僅點亮了 Arduino Nano 33 開發板，同時也透過實現了 BrainFuck 虛擬機器證明了其圖靈完備的能力，最近還驗證了透過凹語言開發 Web 版本貪吃蛇的能力。

7、KCL｜向 WebAssembly 遷移的領域語言

Kusion 配置語言（KCL）是由來自螞蟻的徐鵬飛負責設計的、基於約束的記錄及函式語言。KCL 透過成熟的程式語言技術和實踐來改進對大量繁雜配置比如雲原生場景的編寫，致力於構建圍繞配置的更好的模組化、擴充套件性和穩定性，更簡單的邏輯編寫，以及更快的自動化整合和良好的生態延展性。

作為領域語言，KCL 目前也是基於 LLVM 的能力輸出 WebAssembly 模組，透過 WebAssembly 模組良好的隔離性和跨平臺特性，KCL 可以輕易實現在瀏覽器當中執行。
KCL 語言的主頁：https://kcl-lang.io/

8、其它支援 Wasm 的語言

比如 Zig 等一些語言也支援 Wasm，本質上它們和 C/C++/Rust/TinyGo 一樣，都是依賴 LLVM 的輸出 Wasm 的能力。當然，也有一些採用類似 AssemblyScript 路線，透過 Binaryen 輸出 Wasm。

還有一些特殊場景，比如 OPA 的 Rego 是獨立實現輸出 Wasm 的能力。Wasm 雖然和 C/C++ 採用相似的記憶體模型，但是依然有一些細微的差異，如果希望發揮其最大優勢需要從語言設計和後端輸出兩個方便考慮，這也是很多新語言正在探索的方向。

PART. 6

Wasm 的一些場景

1、Web 應用

隨著 WebAssembly 的成熟，Web 應用不再是 JavaScript 的天下。比如之前就有國外大牛基於 Wasm 技術將 Windows 2000 搬到了瀏覽器中。而像 AutoCAD 和谷歌地球這些重量級的應用均透過 WebAssembly 支援了瀏覽器。

當然，不僅僅是重量級的 Web 應用，隨著 Wasm 原生程式語言的成熟，可以預期會有更多的其他語言開發的 Web 應用。

比如，下面是採用凹語言開發的貪吃蛇小遊戲就是基於 WebAssembly：

貪吃蛇遊戲線上地址：https://wa-lang.org/wa/snake/

2、Web3 和元宇宙應用

隨著 Web3 和元宇宙概念的興起，WebAssembly 也將作為其中的關鍵技術，甚至是基石技術。目前 Web3 相關的區塊鏈行業有大量的技術基於 WebAssembly 構建，甚至專門定製 EWASM 技術標準。

而元宇宙作為數字化和現實完全融合的新社會生態，其底層的軟體系統更是非常依賴純開源軟體和平臺無關的通用技術，因此作者推測 GPL 開源協議和 WebAssembly 技術將會是元宇宙的兩大關鍵支柱。

3、Serverless 應用

Serverless 強依賴高度最佳化的冷啟動，Wasm 非常適合作為下一代無伺服器平臺執行時。SecondState、Cloudflare、Netlify 和 Vercel 等公司都支援透過其邊緣執行時部署 WebAssembly 功能。

下圖是 AWS Lambda 中的 WebAssembly Serverless 函式工作原理：

具體細節可以參考這個文章：https://www.cncf.io/blog/2021/08/25/webassembly-serverless-fu...

4、外掛系統應用

得益於 Wasm 的跨平臺的特性，很多系統和框架在考慮透過 Wasm 開發外掛系統。比如基於 eBPF 和 Wasm 技術實現給 Linux 打動態的補丁。

比如阿里雲剛開源的 Higress 閘道器的外掛系統也支援 Wasm，對比傳統 Nginx 閘道器使用 lua 進行擴充套件，Wasm 的多語言和安全沙箱特性帶來了革命性的變化。同時對比傳統 Nginx 閘道器，修改 lua 程式碼後需要 reload 才能生效，Higress 可以實現外掛的熱分發和熱載入，外掛邏輯發生變化對流量完全無損，長連線也不會斷開。

使用 Go 開發 Higress 外掛可參考：https://higress.io/zh-cn/docs/user/wasm-go.html

比如螞蟻開源的 MOSN (Modular Open Smart Network），是一款主要使用 Go 語言開發的雲原生網路代理平臺。

MOSN 就支援透過 Wasm 外掛來擴充套件其能力。下圖是 MOSN 外掛的工作原理圖：

MOSN 外掛的細節可參考：https://mosn.io/blog/posts/mosn-wasm-framework/

5、微控制器應用

Wasm 不僅僅應用在瀏覽器、雲端計算等行業，在邊緣計算等嵌入式領域也有應用場景。比如 Wasm3 虛擬機器就針對 arduino 提供的更精簡的虛擬機器，使用者可以透過 Wasm 技術為不同的微控制器開發應用。

比如可以透過凹語言結合 Wasm3-arduino 來開發 arduino 的例子，下圖是本地模擬環境程式碼和執行效果圖：

Wasm3-arduino 倉庫：https://github.com/wasm3/wasm3-arduino

PART. 7

Wasm 教程推薦

WebAssembly 屬於這個新生態的根技術、而目前正是處於根技術生態的構建階段。因此，這類推薦的更多是偏向 WebAssembly 規範、原理和實現的教程。我們希望當 WebAssembly 技術正在普及之後，使用者可以透過流行的程式語言直接開發 WebAssembly 應用而不需要關係根技術的細節。

1、《WebAssembly 規範》｜2022

WebAssembly 規範 1.0 草案在 2018 年釋出，現在最新的 WebAssembly 2.0 在 2022 年釋出。

WebAssembly 規範是市面上所有該技術的實現和實踐的參與源頭。任何希望追根溯源、獲取最前沿的 WebAssembly 發展方向的同學不僅僅推薦精讀該規範，甚至還建議跟蹤規範的討論和誕生的過程。

該文件並非正式出版的圖書，目前規範只有線上電子版，建議自行列印。

2、《WebAssembly 標準入門》｜2018

本書是本文作者和前同事於 2018 年合著，主要講解了 WebAssembly 的基礎知識，其內容涵蓋了 Wasm 的歷史背景、Wasm 中組合語言和虛擬機器指令、瀏覽器對 Wasm 的支援、其它高階語言對 Wasm 的支援等。

本書適合想要掌握 WebAssembly 技術、構建對應虛擬機器工具、程式語言或希望瞭解底層細節的使用者學習。

3、《WebAssembly The Definitive Guide》｜2021

這是 Oreilly 出版的相對較新的 WebAssembly 專著，不僅僅覆蓋了規範本身同時結合了主流程式語言的案例。

目前國內還沒有中文版本，大家可以閱讀英文版本。

4、《WebAssembly 原理與核心技術》｜2021

這是國內虛擬機器實現專家張秀宏寫的一本講述如何實現 WebAssembly 虛擬機器的專著。它不僅對 WebAssembly 的工作原理、核心技術和規範進行了全面的剖析和解讀，而且給出了實現 WebAssembly 直譯器和 AOT 編譯器的思路和程式碼。

對於希望嘗試自己實現 WebAssembly 的同學建議閱讀本書。

PART. 8

2023 年展望

對於 WebAssembly 來說，2022 年是真正潤物細無聲開始落地的過程：從新的 2.0 標準到 Ruby、Python 兩大主流指令碼語言開始官方支援，從 SQLite3 開始官方支援、從 Docker 開始官方支援等，到為其而生的凹語言等，到真正的商業應用都有巨大的發展 (而完全不是因為某個大佬的專案黃了就斷言 Wasm 要涼的節奏）。

在商業應用上，Figma 基於 WebAssembly 打造在瀏覽器中的高效能應用，此後被 Adobe 以 200 億美元收購，而 Adobe 也在向瀏覽器遷移。此外，WebAssembly 也是雲廠商、邊緣計算和 Serverless 的候選人。

隨著 WebAssembly 的普及，有一些相關技術流行趨勢也日趨明朗化。作者做 2 個小小的趨勢預測：

1. 首先是 WasmEdge 將成為瀏覽器外最流行的執行時；
2. 其次是 JavaScript 將成為 WebAssembly 平臺上最流行的程式語言。

不過這只是 5 年內的短期預測，更長的發展趨勢還需要看 WebAssembly 生態其他的基礎設施和程式語言發展狀態。

儘管目前 WebAssembly 發展喜人，但百廢待興仍有許多工作要做。我們希望大家更多的是參與到 WebAssembly 建設中去，而不是僅僅作為圍觀者。作為凹語言作者，我們希望在 2023 年真正解決語言的可用性和易用性的問題，讓 WebAssembly 應用構建更加簡單。

WebAssembly 作為一個新興的賽道，作為一個基礎設施必將帶來更大的生態洗牌，這是一個值得關注和投入的方向，讓我們一起攜手共建 Wasm 原生時代。

本週推薦閱讀

SOFARegistry | 聊一聊服務發現的資料一致性

SOFARegistry | 大規模叢集最佳化實踐

MOSN 反向通道詳解

如何看待 Dapr、Layotto 這種多執行時架構？