CNCF在2023年底公布首次Wasm大調查，顯示Wasm應用範圍已擴散到各類型的應用需求，6成開發者用來打造Web應用，35%用於資料視覺化處理，也有3成2用於IoT環境，結合Wasm和AI應用的開發者也高達3成。／CNCF

Wasm技術最吸引開發者的特色，包括了超快啟動速度，可以用於探索新應用，以及可跨專案共享程式碼、可提高JavaScript效能、滿足高運算任務的需求、可到處執行的二進位檔等等。這些都是吸引開發者，讓他們願意，甚至很想用的原因。

開發者打造Wasm應用所用的開發語言排名，JavaScript理所當然是第一名，高達45%，幾乎有一半的Wasm應用採用了JavaScript，其次則是C#（31%）、C++（30%）、Python（29%）和Java（29%）。特別的是，用COBOL這個老牌語言來打造Wasm的開發者竟然也高達15%。超過34%的開發者在開發專案中開始採用WASI，另有34%開發者預計未來一年會採用。

對於可以提供元件模式的WASI專案，多數Wasm開發者都知道這項專案，目前有34%的開發者正在用，也有3成預計未來一年會開始採用。吸引開發者採用WASI的主要原因，高達四成看上了WASI能讓Wasm程式碼具有可移動性（Portability），也能大幅簡化Wasm的部署。另外減少複雜度、提高WebAssembly原生能力和Runtime獨立性，都是WASI受到青睞的原因。目前WASI專案也計畫比照Wasm，申請成為W3C標準，正在提案討論過程中。Wasm開發者最期待WASI未來可以增加HTTP、IO/streams、SQL這三項能力。

根據CNCF在2023年底公布的Wasm大調查，開發者頭號痛點是除錯困難，像是現有除錯工具的支援還不夠，第二項困難是不同Runtime的效能差異很大，導致開發者得自行挑選適合自己應用場景的runtime，增加開發專案管理的複雜度。／CNCF

不過，從這次調查中，也可以看到目前Wasm開發的挑戰和相關工具還不夠成熟，有待發展之初。Wasm開發者最頭痛的三大困難，高達2成開發者認為除錯非常困難，像是現有除錯工具的支援還不夠或是得自己尋找除錯作法，第二項困難是不同Runtime的效能差異很大，這就導致開發者得自行挑選適合自己應用場景的runtime，或是針對不同場景採用不同的runtime，這也增加了開發專案管理的複雜度。第三個挑戰也是runtime的問題，高達15%的Wasm開發者認為現有Wasm runtime的開發者體驗落差太多，彼此的操作習慣，命令語法差異很大，得學習不同套的作法，提高了不少學習門檻和開發複雜度。其他開發挑戰還有像是，缺乏了更完整的工具、學習資源不足、特定瀏覽器有相容問題、需要不少程式碼客制等挑戰。

這些困難都是Wasm目前技術發展的挑戰，也是相關Wasm工具鏈未來的機會。

WASI小組加速發展元件模式，要讓不同語言的Wasm元件直接互動

Cosmonic技術長Bailey Hayes也是WASI小組共同主席。這位將Wasm推廣到瀏覽器以外世界的關鍵推手，在今年初KubeCon歐洲大會的演講中，她介紹了WASI最新的元件模式，目前是預覽第二版，也就是0.2版，吸引了雲原生社群的高度關注。這個WASI元件模式，可以讓不同開發語言所編譯的Wasm程式，有一套標準的輸入輸出方式，互相溝通，甚至放到同一個更大的Wasm元件中互動。舉例來說，用Go語言寫的Wasm元件，和用Rust語言寫的Wasm元件，有共同的標準輸入輸出方式，就像用同一種語言開發的元件一樣，甚至可以把這兩個元件，放入一個更大的Wasm元件中混用。這個元件模型，讓Wasm具備了跨各種語言的能力。

Bailey Hayes指出，元件模式將會限制不同元件只能用標準輸入、輸出管道來確保安全性，但也可以在元件內部建立全域式變數和記憶體，用同一個runtime的跨元件間呼叫速度，甚至可以短到奈秒等級的超高速回應。她預告，新版WASI 0.2版草案標準即將完成，就會納入這個全新的元件模式。

不只如此，WASI在0.2版中，也將開始支援網路能力，換句話說，Wasm元件不只是可以在單一應用環境中彼此溝通，未來也看好能與外部環境，甚至網際網路上的第三方應用元件相互溝通，有了網路溝通能力，也可以讓Wasm元件更適合用來打造一支支微服務程式碼，甚至建立一個全用Wasm元件組成的微服務架構。

下一步，Bailey Hayes預告，WASI預覽第三版的0.3版，要進一步開始讓WASI支援原生的非同步能力，讓瀏覽器外的wasm元件，可以用非同步的方式，來彼此呼叫和協作，這是2025年接下來的發展重點。

後續報導請見：WebAssembly生態圈有哪些重要專案？Wasm生態地圖重點剖析