近日，JetBrains 發(fā)布了 Kotlin 1.8.20 beta 版本，其中包括一項名為“Kotlin/Wasm”的實驗性功能，明確將 WebAssembly 設(shè)為編譯目標。據(jù)介紹，新版本依賴于原生 Wasm 垃圾收集功能 WasmGC，后者同樣處于早期開發(fā)階段。

JetBrains 總結(jié)了 Kotlin/Wasm 的優(yōu)勢：

• 與 wasm32 Kotlin/Native 目標相比，Kotlin/Wasm 的編譯速度更快，因為后者不必使用 LLVM。

• 由于 Wasm 垃圾收集支持，與 wasm32 目標相比，Kotlin/Wasm 與 JS 的互操作性、與瀏覽器的集成更容易。

• 與 Kotlin/JS 和 JavaScript 相比，Kotlin/Wasm 應(yīng)用程序啟動時間可能更快，因為 Wasm 具有緊湊且易于解析的字節(jié)代碼。

• 與 Kotlin/JS 和 JavaScript 相比，Kotlin/Wasm 應(yīng)用程序運行時性能更快，因為 Wasm 是一種靜態(tài)類型語言。

不過，目前還沒有 IDE 為 Kotlin/Wasm 提供支持。JetBrains 在版本發(fā)行說明中提到，“我們以開箱即用的形式，為 Kotlin/Wasm 提供 Kotlin 標準庫（stdlib）和測試庫（kotlin/test）?！?/p>

瀏覽器中運行的 Kotlin/Wasm 演示

此前，通過基于 LLVM 的 Kotlin-Native 編譯指向和 LLVM Wasm 支持，Kotlin 已經(jīng)能夠在某種程度上實現(xiàn)向 Wasm 的編譯，這種舊方法被稱為 wasm32。隨著新版本的發(fā)布，該方法將成為被棄用的多種 Kotlin/Native 編譯目標之一。

作為一種 JVM 語言，Kotlin 具備垃圾收集機制，但此前 Wasm 一直無法原生支持垃圾收集，這就要求各垃圾收集語言自行提供解決方案。Wasm-gc 就是其中一項提案，承諾“對高級語言做出有效支持”。此次，這一設(shè)計有望超越自定義解決方案，并減少應(yīng)用程序的二進制文件大小。Wasm-gc 可通過瀏覽器 Flag 在最新版本的 Chrome、Firefox 和 Edge 上啟用。

早在 2017 年，主流瀏覽器都已經(jīng)支持 WebAssembly。隨著 WebAssembly 的蓬勃發(fā)展，各種編程語言也在增加對其的支持。比如，C/C++、Rust、Golang 等已支持將語言編譯到 WebAssembly 目標平臺，Lua、JavaScript、Ruby 和 Python 等支持將語言的虛擬機或解釋器編譯到 WebAssembly 平臺。

2021 年，WebAssembly 開源項目開始支持 GC（垃圾回收器），為實現(xiàn) WebAssembly 支持像 Java、Kotlin 這樣的前端語言做準備。同年，Kotlin 程序語言開發(fā)團隊更新了發(fā)展路線，其中的一個重點就是增加 WebAssembly 支持。

Kotlin 總項目經(jīng)理 Egor Tolstoy 表示，他們認為 WebAssembly 會成為未來創(chuàng)建豐富網(wǎng)頁應(yīng)用程序的新標準，而 Kotlin 必需要能夠完美的提供支持。因此官方火力全開，組建了一個專門團隊來開發(fā) Kotlin/Wasm 工作，并且與 WebAssembly 垃圾回收提案作者緊密合作，要實現(xiàn) Kotlin 語言的基本功能、函數(shù)庫和基本 Gradle 的支持，還要添加實驗性 JavaScript 互通操作功能。

Kotlin 在 2017 Google 發(fā)表聲明后總被當成是安卓專用開發(fā)語言，但實際上，Kotlin 正在積極地向多平臺語言演進，即“通用型語言”。

如今，JetBrains 提供了多個支持多平臺的庫，如 kotlinx.coroutines、kotlinx.serialization、kotlinx-datetime。而 Kotlin 社區(qū)也緊跟著這樣的趨勢發(fā)展，出現(xiàn)了愈來愈多的庫、框架來支持多平臺，如 Arrow、Okio、Apollo 等在新版本中都支持了多平臺開發(fā)。

在最初的設(shè)計中，WebAssembly 只是 C、C++ 或 Rust 這些低級語言的編譯目標。至于 Python、Ruby 甚至是 JavaScript 等動態(tài)語言，能充當解釋性的虛擬機即可。

但 WebAssembly 垃圾收集（GC）的貢獻者們正努力把它打造成垃圾收集語言（例如 Java、Kotlin 或 Dart）的編譯目標，并停止使用 JavaScript 作為 Web 字節(jié)碼。此外，他們還考慮把其他語言也都轉(zhuǎn)化成前端開發(fā)中的理想選項，而不必像 TypeScript 那樣把一切先編譯成 JavaScript。

請注意，這些語言已經(jīng)能夠在各個應(yīng)用程序內(nèi)提供自己的自定義垃圾收集，借此實現(xiàn)對 WebAssembly 的編譯。這樣做的缺點就是這樣生成的工件會更大，所以也不知道 WasmGC 真正推出時，原來的這種處理方式還有沒有競爭力。

WasmGC 的實現(xiàn)源自 Chrome、Firefox、Edge 和 Safari 四大瀏覽器的一個持續(xù)性項目，目前需要使用 Flag 加以啟用（例如，在 Chrome 或 Edge 上，需要使用 --js-flags=--experimental-wasm-gc 命令行參數(shù)）。正是因為達不到開箱即用的程度，所以該技術(shù)目前還沒能得到廣泛采用。

但是，當 WasmGC 步入第四階段并在大多數(shù)瀏覽器中實現(xiàn)開箱即用后，能夠利用 WasmGC 的語言將迎來顯著的競爭優(yōu)勢。

在 VMware 從事 Spring Framework 工作的 Sébastien Deleuze 稱，Kotlin/Wasm 很早就在關(guān)注 WasmGC，谷歌也在使用 J2CL 和 Dart 在 Google Sheets 中將 Java 編譯為 WasmGC。

“因為要求開發(fā)者同時了解 Kotlin 和 JavaScript 兩套生態(tài)系統(tǒng)，所以我個人一直對 Kotlin/JS 不太感冒，但 Kotlin/Wasm 確實是個重塑前端開發(fā)面貌的好機會?！盌eleuze 表示，“當然，Kotlin/Wasm 必須要提供良好的 JavaScript 互操作性（它也確實做到了），并作為可選項?！?/p>

目前，Kotlin/Wasm 提供 DOM API，所以某些 Kotlin/Wasm 前端框架可能已經(jīng)足夠成為前端開發(fā)的理想選擇。Deleuze 表示自己可能也會試試將 Kotlin/Wasm 用于前端開發(fā)，再配合 Spring Boot Kotlin/JVM 后端實現(xiàn) Kotlin 中的全棧開發(fā)。

但從另一個角度來看，WebAssembly 還有更多值得發(fā)掘的亮點。如果 Compose for Web（Android 上使用的多平臺版 Jetpack Compose）能夠用 Kotlin/Wasm 代替 Kotlin/JS 來完美執(zhí)行基于 Canvas 的像素渲染，結(jié)果又會如何？（稍做劇透，其實已經(jīng)實現(xiàn)了。）

如果 Kotlin/Wasm 能夠用 WebAssembly 來取代 JavaScript，支持一種新的 Jamstack 架構(gòu)，結(jié)果又會如何？

要想充分理解 Kotlin/Wasm 的巨大潛力，就不能不提 WebAssembly 組件模型。正是它的存在，讓我們能使用任意支持 WebAssembly 的語言，為 WebAssembly 開發(fā)組件。這項工作的基石正是 WIT 格式，可用于描述導入和展出并生成特定于語言的 binding。

Deleuze 親自實踐了一下，看看 WIT 是如何被轉(zhuǎn)譯成 Kotlin 的，結(jié)果看起來還不錯。例如，其嘗試將 WIT variant 定義為：

variant filter {
    all,
    none,
    some(list<string>),
 }

轉(zhuǎn)譯出的 Kotlin 代碼如下：

sealed interface Filter {
   object All : Filter
   object None : Filter
   class Some(val value: List): Filter
}

利用 String 提供的 null 安全特性，WIT option能夠被準確轉(zhuǎn)譯為 Kotlin 慣用的選項值處理方式。在 Deleuze 看來，Kotlin 協(xié)程也將成為組件模型異步支持綁定中一個強大的競爭優(yōu)勢。

大家可能會好奇 WebAssembly 要如何發(fā)布和使用。別擔心，面向 WebAssembly 包的標準化管理項目 Warg，有望帶來各種包 repo 實例，其中的關(guān)鍵就是 WebAssembly 包 repo 將支持多語言。

沒錯，Maven Central 或者 NPM 在 Java 和 JavaScript 之外的語言中也有使用，但無論是生產(chǎn)還是消費都擺脫不了“二等公民”的陰影。Warg 和 WebAssembly 將真正把多語言組件推向全新的高度。

Deleuze 預測，像 Rust/C/C++ 這樣的語言將主要用于生產(chǎn) Wasm 組件（強調(diào)效率，只為非共享方法提供極小、甚至干脆不提供運行時）；而 Kotlin/Wasm 這類能利用 WasmGC 的語言，則主要負責構(gòu)建使用這些組件的應(yīng)用程序。當然，Rust 也可以用來開發(fā) Wasm 應(yīng)用程序，但 Deleuze 猜測 WasmGC 語言才是這類用例中的主導者。

所謂 WASI，簡言之就是在定義標準化系統(tǒng)接口（包括文件系統(tǒng)、時鐘、環(huán)境變量、命令行參數(shù)或者標準輸入 / 輸出）應(yīng)該如何被公開給 Wasm 應(yīng)用程序。機器學習、人工智能或者云存儲等其他用例也可以通過 WASI 進行標準化。

Kotlin/Wasm 目前還不支持 WASI，但開發(fā)團隊已經(jīng)提供低級 API 實現(xiàn)。有趣的是，只需要提供 WASI 平臺中的特定部分，就能使用 Kotlin 的多平臺庫（例如 kotlinx-datetime 或 Okio）。

“ Kotlin/Wasm + WASI ”將并發(fā)出驚人的潛能：它可以提供 Kotlin/JVM 的替代方案，將應(yīng)用程序部署到云端、邊緣甚至是 Serverless 函數(shù)的形式；也被大量用作容器鏡像的替代方案，能在幾微秒內(nèi)完成實例化、提供更高的安全性且不依賴于任何特定硬件或操作系統(tǒng)。這樣的特性可能讓人想起 Java 在 1995 年提出的“一次編寫，隨處運行”（WORA）口號。

目前實現(xiàn)這一愿景的主要障礙在于，Wasmtime 等純 WASI 運行時還不支持 WasmGC。目前，運行 Kotlin/Wasm WASI 應(yīng)用程序的主要途徑是利用 Node WASI 支持。

要啟用 Kotlin/Wasm 并對其進行測試，請更新您的 build.gradle.kts 文件：

plugins {
    kotlin("multiplatform") version "1.8.20-Beta"
}


kotlin {
    wasm {
        binaries.executable()
        browser {
        }
    }
    sourceSets {
        val commonMain by getting
        val commonTest by getting {
            dependencies {
                implementation(kotlin("test"))
            }
        }
        val wasmMain by getting
        val wasmTest by getting
    }
}

可查看包含 Kotlin/Wasm 示例的 GitHub 存儲庫

要運行 Kotlin/Wasm 項目，您需要更新目標環(huán)境的設(shè)置：

• Chrome，對于版本 109 或更高版本：

1. 在您的瀏覽器中轉(zhuǎn)到 chrome://flags/#enable-webassembly-garbage-collection。

2. 重新啟動瀏覽器應(yīng)用程序。

• Firefox，對于版本 111 或更高版本：

3. 在您的瀏覽器中轉(zhuǎn)到 about:config。

4. 啟用 javascript.options.wasm_function_references 和 javascript.options.wasm_gc 選項。

5. 重新啟動瀏覽器應(yīng)用程序。

• Edge，對于版本 109 或更高版本：

使用命令行參數(shù)運行應(yīng)用程序 -- js-flags=--experimental-wasm-gc。

審核編輯 ：李倩