導(dǎo)讀WebAssembly（Wasm）已經(jīng)誕生了五年在云原生領(lǐng)域，這段時(shí)間并不算短，畢竟堪稱業(yè)界標(biāo)準(zhǔn)的Kubernetes也才出現(xiàn)八年作為一種供基于堆棧的虛擬機(jī)....

WebAssembly（Wasm）已經(jīng)誕生了五年在云原生領(lǐng)域，這段時(shí)間并不算短，畢竟堪稱業(yè)界標(biāo)準(zhǔn)的 Kubernetes 也才出現(xiàn)八年作為一種供基于堆棧的虛擬機(jī)使用的二進(jìn)制指令格式，Wasm 想讓開發(fā)者實(shí)現(xiàn)“一次構(gòu)建、隨處運(yùn)行”，因此被廣泛認(rèn)為具有改變游戲規(guī)則的潛力，接下來我們就來聊聊關(guān)于webassembly有啥用?以下內(nèi)容大家不妨參考一二希望能幫到您!

webassembly有啥用

WebAssembly（Wasm）已經(jīng)誕生了五年。在云原生領(lǐng)域，這段時(shí)間并不算短，畢竟堪稱業(yè)界標(biāo)準(zhǔn)的 Kubernetes 也才出現(xiàn)八年。作為一種供基于堆棧的虛擬機(jī)使用的二進(jìn)制指令格式，Wasm 想讓開發(fā)者實(shí)現(xiàn)“一次構(gòu)建、隨處運(yùn)行”，因此被廣泛認(rèn)為具有改變游戲規(guī)則的潛力。

但 HTTP Archive 發(fā)布的 2022 年 Web 技術(shù)報(bào)告顯示：“WebAssembly 的應(yīng)用還不夠廣泛，我們并沒有發(fā)現(xiàn)使用量的增加，反而看到了小幅收縮。”

WebAssembly 語言使用情況，圖源：https://almanac.httparchive.org/en/2022/webassembly#fig-5

這份報(bào)告基于對(duì) 800 多萬個(gè)網(wǎng)站的調(diào)查，這些網(wǎng)站是谷歌 Chrome Chrome UX Report（用戶體驗(yàn)報(bào)告）所分析的網(wǎng)站。據(jù) Netcraft 的月度調(diào)查顯示，有超過 11 億個(gè)網(wǎng)站，但其中許多網(wǎng)站并不活躍，因此這份報(bào)告僅針對(duì)那些最活躍的網(wǎng)站。

需要注意的是，通常情況下，網(wǎng)絡(luò)爬蟲并不會(huì)登錄 Web 應(yīng)用，它們只能瀏覽網(wǎng)站上的公開內(nèi)容，因此這項(xiàng)調(diào)查并不包括那些使用中的 Web 技術(shù)應(yīng)用。當(dāng)涉及更加以應(yīng)用為核心的技術(shù)時(shí)，則可能會(huì)導(dǎo)致結(jié)果失真，包括 WebAssembly。

盡管如此，在報(bào)告中撰寫 WebAssembly 分析的技術(shù)博主 Colin Eberhardt 并沒有放棄，他指出，網(wǎng)頁中的 Wasm（編譯的 WebAssembly 代碼）數(shù)量很少：

“我們發(fā)現(xiàn)，在桌面上有 3204 個(gè)確認(rèn)的 WebAssembly 請(qǐng)求，移動(dòng)端有 2777 個(gè)。這些模塊被用于桌面上的 2524 個(gè)域名和移動(dòng)上的 2216 個(gè)域名，分別占桌面和移動(dòng)上所有域名的 0.06%和 0.04%。”

對(duì)該 Wasm 的分析表明，到目前為止，最大的份額是亞馬遜 IVS（互動(dòng)視頻服務(wù)），這是 AWS Chime 服務(wù)用于優(yōu)化視頻通信的庫(kù)模塊。這并不代表開發(fā)者有意為之，僅僅是使用這種特定的 AWS 服務(wù)的結(jié)果。也許更重要的是，微軟的 Blazor 框架出現(xiàn)在最普遍 Wasm 使用的第三位，因?yàn)檫@將是開發(fā)者為特定網(wǎng)站而編寫的代碼。

流行的 WebAssembly 庫(kù)，圖源：https://almanac.httparchive.org/en/2022/webassembly#fig-4

Eberhardt 認(rèn)為，目現(xiàn)在還沒有充分的理由去使用 WebAssembly，原因是 Wasm 代碼不能替代 JavaScript，它只能作為 JavaScript 的補(bǔ)充。他認(rèn)為，WebAssembly 的未來可能不是“作為一個(gè)小眾的 Web 技術(shù)，而是作為一種在其他平臺(tái)上完全主流的運(yùn)行時(shí)”。

為什么 Wasm 就一直火不起來？雖然有各種各樣的原因，但 Wasm 自身生態(tài)系統(tǒng)的震蕩不定卻是難辭其咎。

AssemblyScript 的分裂

最近幾周，Wasm 生態(tài)的問題再度暴露無遺。

AssemblyScript 是一種專為 Wasm 在瀏覽器中使用所設(shè)計(jì)的語言。最近，其宣布不再支持 WASI——一種易于在瀏覽器之外使用的 Wasm 系統(tǒng)接口。目前還不清楚 AssemblyScript 到底為什么要放棄 WASI，但理由大概率還是在技術(shù)和觀點(diǎn)層面有分歧。

WASI 項(xiàng)目提案?jìng)?cè)重于 Wasm 與 Rust、C 等語言的互操作性，相對(duì)犧牲了 JavaScript，而這最終會(huì)損害 AssemblyScript（具有 TypeScript 特性）的利益，并迫使其在項(xiàng)目層面做出重大更改。

AssemblyScript 的作者們通過線上文檔《對(duì)標(biāo)準(zhǔn)的反對(duì)意見》提出，W3C 的 WASI 子團(tuán)隊(duì)“擴(kuò)大了職能范圍”，其“設(shè)計(jì)的自有提案……會(huì)與既定或當(dāng)前設(shè)計(jì)的 Web 標(biāo)準(zhǔn)相競(jìng)爭(zhēng)。”

除此之外，作者們還表示，“我們的代表受到了系統(tǒng)性歧視，沒人在乎他們表達(dá)的擔(dān)憂和反對(duì)。”

再者，AssemblyScript 還將矛頭指向 Bytecode 聯(lián)盟。該聯(lián)盟擁有多家重量級(jí)技術(shù)成員，包括亞馬遜、谷歌和微軟三大云服務(wù)巨頭，專司為 Wasm 和 WASI 提供支持。

AssemblyScript 的作者們警告稱，“我們想提醒公眾，應(yīng)密切關(guān)注潛在的反競(jìng)爭(zhēng)行為。有必要的時(shí)候，甚至應(yīng)該要求反壟斷立法的介入。”

這里再介紹一點(diǎn)相關(guān)背景：有數(shù)據(jù)表明，人們對(duì)于 AssemblyScript 的關(guān)注正在下降。在 Scott Logic 今年 6 月發(fā)布的《2022 年 WebAssembly 現(xiàn)狀調(diào)查》中，只有 17%的受訪者表示有意在未來大量使用 AssemblyScript，比例遠(yuǎn)低于 2021 年調(diào)查時(shí)的 26%。

雖然這一結(jié)果可能跟 Wasm 項(xiàng)目范圍擴(kuò)大而導(dǎo)致 AssemblyScript 用量稀釋有關(guān)，但必須承認(rèn)，當(dāng)前對(duì)開發(fā)者吸引力最大的仍然是 Go 和 JavaScript 那幾種熱門語言。AssemblyScript 在其中的確缺乏競(jìng)爭(zhēng)力。

至于反競(jìng)爭(zhēng)指控，雖然 Bytecode 聯(lián)盟的成員名單確實(shí)有利益集團(tuán)綁定的嫌疑，但這更多是種對(duì)強(qiáng)勢(shì)技術(shù)趨勢(shì)的主動(dòng)參與，未必代表各方打算強(qiáng)行通過有利于自己的議程。

Bytecode 聯(lián)盟成員、邊緣云平臺(tái)廠商 Fastly 公司首席技術(shù)官 Tyler McMullen 表達(dá)了他對(duì)這波沖突的失望之情。

McMullen 強(qiáng)調(diào)，癥結(jié)其實(shí)就是“一個(gè)非常細(xì)微的技術(shù)細(xì)節(jié)——是否允許在客串中包含某些無效代碼點(diǎn)。” 他指出，這個(gè)“技術(shù)細(xì)節(jié)”的決定并不是某個(gè)人或一家公司說了算，“提案經(jīng)過了整個(gè)行業(yè)中很多專家的審查和投票，包括各家主要瀏覽器開發(fā)商。”

開源平臺(tái)工具廠商 Suborbital 工程總監(jiān)、Grain 編程語言聯(lián)合締造者 Oscar Spencer 也有類似判斷：

“這可能引發(fā)碎片化趨勢(shì)，阻礙標(biāo)準(zhǔn)的發(fā)展和進(jìn)步，肯定不利于建立起有凝聚力的生態(tài)系統(tǒng)。”

推廣 Wasm 的力量來源并非用戶

鑒于這樣的沖突和分歧，整體軟件社區(qū)找不到使用 Wasm 的理由和必要性。

盡管 Wasm 最初專門為瀏覽器所設(shè)計(jì)，但現(xiàn)在這類用例似乎不是特別重要。大家更多的關(guān)注和興趣主要集中到 Wasm 在瀏覽器之外的潛力，例如在服務(wù)器上使用（有望與 Docker 結(jié)合使用，甚至直接替代 Docker），或者通過代碼捆綁實(shí)現(xiàn)跨多應(yīng)用程序運(yùn)行。

Spencer 對(duì)于 Wasm 的發(fā)展歷程也有自己的看法：

“我們最終看到……JavaScript 引擎其實(shí)已經(jīng)很快了。單純用 Wasm 重寫現(xiàn)有應(yīng)用程序，其實(shí)并不一定能讓它變得更快，畢竟 JavaScript 引擎已經(jīng)有了幾十年的積累，目前非常成熟且完善。”

“正因?yàn)槿绱耍跒g覽器上用 Wasm 編寫完整應(yīng)用程序的需求越來越少。現(xiàn)在的開發(fā)者更多在用 Wasm 編寫那些對(duì)速度比較敏感的后臺(tái)任務(wù)。”

但這并不是說 Wasm 在 Web 世界失去了生命力。相反，它找到了最適合自己的利基市場(chǎng)：強(qiáng)調(diào)速度和性能的場(chǎng)景。

全球開源咨詢公司 Igalia 軟件工程師 Andy Wingo 提到，他最近剛剛為某受眾龐大、基于瀏覽器的電子表格做了一個(gè)項(xiàng)目。在此項(xiàng)目中，他希望“提高 JavaScript 與 Wasm 之間的字符串轉(zhuǎn)換效率。”在他看來，這類項(xiàng)目屬于“大型利益相關(guān)方與瀏覽器開發(fā)商間的一對(duì)一合作”，也是 Wasm 最常見的應(yīng)用環(huán)境之一。

這也再一次提醒我們，雖然新興技術(shù)總能引發(fā)炒作熱情與激烈討論，但其最終命運(yùn)仍然要由非常具體的用例來決定。

Wingo 還提到，F(xiàn)astly 和電子商務(wù)平臺(tái) Shopify 等企業(yè)也在使用 Wasm，而這兩家公司之所以選擇 Wasm，是因?yàn)楣?yīng)商們喜歡用。“所以，推廣 Wasm 的力量之源并不是用戶，而是先由平臺(tái)所有者的意愿決定，再一步步傳導(dǎo)至用戶群體當(dāng)中。”

Wingo 的觀點(diǎn)跟 McMullen 可謂不謀而合，即：并不是所有平臺(tái)都支持 Wasm，“之所以無法廣泛支持，是因?yàn)?Wasm 難以嵌入。而導(dǎo)致難以嵌入的原因之一，就是 Wasm 缺乏標(biāo)準(zhǔn)的交互模型。”

因此，盡管大家普遍對(duì) Wasm 的速度和性能優(yōu)勢(shì)贊不絕口、給予關(guān)注，但在實(shí)際應(yīng)用方面仍存在很大的爭(zhēng)議甚至是分歧。

局外人眼中的 Wasm

對(duì)局外人來說，Wasm 是種相當(dāng)奇怪的語言。

首先，這種語言最初的用途定位跟后來真正讓它聲名鵲起的用例幾乎沒有關(guān)系，但在脫離瀏覽器的過程中，Wasm 也確實(shí)變得更加流暢靈活。于是問題來了：現(xiàn)在的 Wasm，還是當(dāng)初設(shè)想的那個(gè) Wasm 嗎？

也許正是存在這個(gè)問題，才導(dǎo)致 Wasm 在標(biāo)準(zhǔn)制定方面遭遇困境——由于缺乏明確的共識(shí)，不同群體都在朝著自己心中正確的方向發(fā)力。

這對(duì)用戶和潛在的 Wasm 開發(fā)者來說當(dāng)然不是好消息。Wingo 表示，“人們其實(shí)都或多或少知道 Wasm 的一些特性，只是不清楚為什么會(huì)這樣。”

但這也未必是壞事，反而凸顯出 Wasm 面臨的最大挑戰(zhàn)，即如何將其在瀏覽器中安全高效運(yùn)行任意代碼的能力在制定項(xiàng)目中成功應(yīng)用。只要解決這點(diǎn)，Wasm 必然能夠一飛沖天。

Spencer 對(duì)此表示贊同，并在采訪中坦言大多數(shù)嘗試 Grain 的用戶其實(shí)是想借此探索 Wasm。其實(shí)很多用戶都“愿意在 Wasm 當(dāng)中做一些嘗試”，只是發(fā)現(xiàn)跟 Rust 或 C 等其他語言相比，Wasm 真的讓人望而生畏。

雖然編程語言的實(shí)質(zhì)就是幫助人們觸及那些無比復(fù)雜的邏輯和事物。但有趣的是，Scott Logic 調(diào)查給出的數(shù)據(jù)，其實(shí)跟 Spencer 的觀點(diǎn)相互矛盾：

在將 Rust 與 Wasm 結(jié)合使用的開發(fā)者當(dāng)中，有 24%的受訪者表示未來想要試試 Grain。而在其余的調(diào)查參與者當(dāng)中，只有 7%的受訪者表示有意嘗試 Grain。

看起來，雖然 Grain 是專門為了降低 Wasm 門檻而生，但有能力解決復(fù)雜工程問題的人們也完全不抗拒這種更簡(jiǎn)單的方法工具。

Grain 項(xiàng)目的主頁上寫道：很多語言都有著絕佳的設(shè)計(jì)思路，但最終卻因?yàn)檫^于深?yuàn)W難學(xué)而致人放棄，無法建立起龐大的技術(shù)社區(qū)。Grain 希望為這些思路帶來新的活力，通過易于使用、理解的方式加以呈現(xiàn)。

這么看來，Grain 存在本身也許正是 Wasm 生態(tài)系統(tǒng)的最大短板——這證明 Wasm 沒能用簡(jiǎn)單易行的方法，幫助開發(fā)者們了解如何用它解決問題。

互聯(lián)網(wǎng)上關(guān)于這個(gè)問題的討論很多。

在 Quora 上，IT 支持軟件廠商 Licorice 的 CTO Julian Jensen 就回答了 Wasm 是否難以上手的問題。

“這個(gè)主題下的幾乎每篇文章，都涉及如何在瀏覽器中加載和執(zhí)行某些非常簡(jiǎn)單的功能。”

“這類回答著實(shí)沒有營(yíng)養(yǎng)。它們無法反映大家在現(xiàn)實(shí)開發(fā)中遇到的問題，也沒能觸及嚴(yán)肅項(xiàng)目中可能遇到的任何痛點(diǎn)。”

Jensen 的看法可能有些偏激，但他的基本判斷是對(duì)的：雖然很多人都對(duì) Wasm 抱有興趣，但 Wasm 的生態(tài)系統(tǒng)始終沒能提供一種簡(jiǎn)便易行的學(xué)習(xí)方式。

更重要的是，這也凸顯出 Wasm 面臨的一大核心挑戰(zhàn)：如何在幫助廣大開發(fā)者降低理解門檻的同時(shí)，確保 Wasm 自身的很多特性不致因過度簡(jiǎn)化而失去意義？

WebAssembly 組件模型

于是問題又回到了標(biāo)準(zhǔn)化上。沒有標(biāo)準(zhǔn)化，我們就永遠(yuǎn)無法把大肆宣揚(yáng)的各種技術(shù)期望變成現(xiàn)實(shí)。目前，最有前途的方案就是 WebAssembly 組件模型。

根據(jù) Spencer 的說法，就是因?yàn)樨?fù)責(zé)這項(xiàng)工作的小組始終達(dá)不成共識(shí)，才“真正阻止了……Wasm 的全面崛起。”McMullen 也回應(yīng)了這種說法，表示組件模型對(duì)于保障“標(biāo)準(zhǔn)交互模型”至關(guān)重要，甚至直接決定著 Wasm 能得到多少支持。

組件模型的意義在于簡(jiǎn)化 Wasm 在瀏覽器以外的使用方式。通過為不同事物間的協(xié)同運(yùn)行編寫出規(guī)則和規(guī)范，組件模型應(yīng)該能夠消除 Wasm 實(shí)際應(yīng)用中的不少認(rèn)知負(fù)擔(dān)（和額外代碼）。

“組件模型的關(guān)鍵，是讓代碼得以跨語言和生態(tài)系統(tǒng)實(shí)現(xiàn)安全高效共享與連接。除此之外，組件模型還有望幫助 Wasm 建立起睽違已久的代碼公開接口。只有通過更高級(jí)的方式定義這些接口，我們才能就跨語言和平臺(tái)的工作模式和標(biāo)準(zhǔn)達(dá)成一致。”McMullen 表示。

盡管組件模型對(duì)整個(gè) Wasm 項(xiàng)目都具有重要意義，但 W3C WebAssembly 社區(qū)小組仍在討論其中的具體細(xì)節(jié)，而且整個(gè)過程可能還需要一些時(shí)間。

Spencer 注意到，盡管大家的出發(fā)點(diǎn)都是好的，但由于民主化程度過高，人們其實(shí)是在相互內(nèi)耗、把大量時(shí)間浪費(fèi)在了對(duì)于小細(xì)節(jié)的爭(zhēng)論上。

那么，距離最終定稿還有多久？Spencer 表示，他覺得具體實(shí)施可能要等到 2023 年春季去了。McMullen 則強(qiáng)調(diào)，目前的延誤其實(shí)有其道理：

“大多數(shù)工業(yè)標(biāo)準(zhǔn)都不及 Wasm 及其配套標(biāo)準(zhǔn)那么嚴(yán)格。這里需要極其精確的措辭，并最終以數(shù)學(xué)形式編寫，這樣才能對(duì)其正確性做出強(qiáng)有力的證明。”

“特別是組件模型，它要做的是定義一項(xiàng)標(biāo)準(zhǔn)，借此跨越多種語言、異步模型、線程模型和行業(yè)，同時(shí)保持極高的運(yùn)行效率和安全水平。”

盡管進(jìn)展緩慢，但 Spencer 和 McMullen 對(duì)這項(xiàng)工作的重要意義都給予了充分肯定。Spencer 坦言，Wasm 的命運(yùn)由工具鏈決定，畢竟開發(fā)者最關(guān)心的就是一種語言有沒有完備的工具鏈。

Wasm 會(huì)落入專有陷阱嗎？

脫離瀏覽器之后的 Wasm，其未來命運(yùn)似乎就取決于組件模型能否一戰(zhàn)成功。但在此之后，Wasm 還須著眼于更廣泛的軟件市場(chǎng)。

Wingo 預(yù)計(jì)，屆時(shí)會(huì)有風(fēng)險(xiǎn)投資入駐這個(gè)領(lǐng)域，其中一些可能愿意遵循標(biāo)準(zhǔn)，但也有一些可能想讓 Wasm 走向?qū)Ｓ墟i定。

也許 Shopify 和 Fastly 等公司的當(dāng)前貢獻(xiàn)，就是在為后續(xù)的專有演變做鋪墊。唯一的問題就是，供應(yīng)商們能不能把 Wasm 輕松打包成邊緣計(jì)算解決方案。只要 Wasm 項(xiàng)目的開發(fā)門檻不高，就會(huì)有更多工程師熟悉這項(xiàng)技術(shù)，最終影響供應(yīng)商對(duì)于 Wasm 類方案的設(shè)計(jì)思路。

而且 Bytecode 聯(lián)盟也未必就有壟斷 Wasm 的想法。McMullen 更愿意將聯(lián)盟視為 Wasm 的“元生態(tài)系統(tǒng)”。“我們絕不會(huì)在 Wasm 之內(nèi)搞一言堂。我們所需要的不只是一種語言，更是多樣性的平臺(tái)和行業(yè)。”

結(jié)束語

無論風(fēng)險(xiǎn)投資方們?cè)趺粗\劃、無論項(xiàng)目各種 fork 背后的核心開發(fā)團(tuán)隊(duì)選擇哪條路線，Wasm 本身永遠(yuǎn)是一項(xiàng)重要且極具價(jià)值的技術(shù)，完全有能力在正確的場(chǎng)景下改變游戲規(guī)則。

所以，最大的難題其實(shí)就是，怎么按捺住激動(dòng)的心、顫抖的手，忍著別把 Wasm 的影響力和價(jià)值抽象化成特定某一種軟件工程工具。

Spencer 強(qiáng)調(diào)，歸根結(jié)底，Wasm 只是一種編譯器目標(biāo)、一種實(shí)現(xiàn)細(xì)節(jié)。如果 Wasm 能在未來幾年內(nèi)把自己的問題解決好，那它就會(huì)從流行詞轉(zhuǎn)化為潤(rùn)物細(xì)無聲的開發(fā)方式。

這樣的未來看似簡(jiǎn)單，也是 Wasm 最合理的發(fā)展目標(biāo)。但縱觀整個(gè)發(fā)展歷程，要讓這個(gè)目標(biāo)真正落地，還需要解決大量爭(zhēng)論、探索、實(shí)驗(yàn)和共識(shí)。

參考鏈接：

https://thenewstack.io/whats-stopping-webassembly-from-widespread-adoption/

https://devclass.com/2022/09/29/massive-web-tech-survey-shows-how-bad-habits-continue-and-webassembly-may-be-over-hyped/?td=rt-3a