【譯】爲何 WebAssembly 這麼重要？

本文做者：Michael van der Gulik

原文連接：《Why WebAssembly is a big deal》

譯者與來源：敖小劍，敖小劍的博客

本文已得到譯者轉載受權

編者按：Michael van der Gulik 在《Why WebAssembly is big deal》一文中，詳盡探索了 WebAssembly 在瀏覽器的實際用處，好比能夠直接從網絡獲取應用，無需下載。但更爲重要的是，Michael van der Gulik 在本文中還探索了 WebAssembly 在硬件與雲計算的巨大潛力。

如下爲正文：

WebAssembly 是每一個程序員都應該關注的技術。WebAssembly 會變得更流行。WebAssembly 將取代 JavaScript。WebAssembly 將取代 HTML 和 CSS。WebAssembly 將取代手機應用。WebAssembly 將取代桌面應用。在 10 年內，我保證每一個程序員至少須要知道如何使用工具來操做 WebAssembly 並理解它是如何工做的。

你可能會說，「太離譜了！」 好吧，請繼續閱讀。

什麼是 WebAssembly

當前形式的 WebAssembly 是 Web 瀏覽器的新擴展，能夠運行預編譯代碼…快速地。在 C ++ 中編寫了一些小代碼，而後使用 Emscripten 編譯器將該代碼編譯爲 WebAssembly。經過一些 Javascript 粘合，就能夠在 Web 瀏覽器中調用這一小段代碼，例如，運行粒子模擬。

WebAssembly 文件，擴展名爲.wasm，自己是包含可執行指令的二進制格式。要使用該文件，必須編寫一個運行某些 Javascript 的 HTML 文件來獲取、編譯和執行 WebAssembly 文件。WebAssembly 文件在基於堆棧的虛擬機上執行，並使用共享內存與其 JavaScript 包裝器進行通訊。

到目前爲止，這彷佛並不有趣。它看起來只不過是 JavaScript 的加速器。可是，聰明的讀者會對 WebAssembly 可能成爲何有所瞭解。

WebAssembly 將成爲何？

第一個重要發現是 WebAssembly 是一個安全的沙盒虛擬機。能夠從 Internet 運行喜歡的 WebAssembly 代碼，而確保它不會接管 PC 或服務器。四個主流 Web 瀏覽器對它的安全性很是有信心，它已經默認實現並啓用了。它的真正安全性還有待觀察，但安全性是 WebAssembly 的核心設計目標。

第二個重要發現是 WebAssembly 是一個通用的編譯目標。它的原始編譯器是一個 C 編譯器，這個編譯器很好地指示了 WebAssembly 虛擬機的低級和可重定向性。許多編程語言都使用 C 語言編寫虛擬機，其餘一些語言甚至使用 C 自己做爲編譯目標。

此時，有人整理了一個能夠編譯爲 WebAssembly 的編程語言列表。這份名單將在將來不少年中繼續增加。

WebAssembly 容許使用任何編程語言編寫代碼，而後讓其餘人在任何平臺上安全地運行該代碼，無需安裝任何內容。朋友們，這是美美夢想的開始。

部署問題

咱們來談談如何將軟件提供給用戶。

爲新項目選擇編程語言的一個重要因素是如何將項目部署到客戶。您的程序員喜歡用 Haskell，Python，Visual Basic 或其餘語言編寫應用程序，具體取決於他們的喜愛。要使用喜歡的語言，他們須要編譯應用，製做一些可安裝的軟件包，並以某種方式將其安裝在客戶端的計算機上。有許多方法能夠提供軟件 - 包管理器，可執行安裝程序或安裝服務，如 Steam，Apple App Store，Google Play 或 Microsoft store。

每個安裝機制都意味着痛苦，從應用商店安裝時的輕微疼痛，到管理員要求在他的 PC 上運行一些舊的 COBOL 代碼時的集羣頭痛。

部署是一個問題。對於開發人員和系統管理員來講，部署一直是一個痛點。咱們使用的編程語言與咱們所針對的平臺密切相關。若是大量用戶在 PC 或移動設備上，咱們使用 HTML 和 Javascript。若是用戶是 Apple 移動設備用戶，咱們使用……呃…… Swift？（我實際上不知道）。若是用戶在 Android 設備上，咱們使用 Java 或 Kotlin。若是用戶在真實計算機上而且願意處理掉他們的部署問題，那麼咱們開發人員才能在咱們使用的編程語言中有更多選擇。

WebAssembly 有可能解決部署問題。

有了 WebAssembly，您可使用任何編程語言編寫應用，只要這些編程語言能夠支持 WebAssembly，而應用能夠在任何設備和任何具備現代 Web 瀏覽器的操做系統上運行。

硬件壟斷

想購買臺式機或筆記本電腦。有什麼選擇？好吧，有英特爾，有 AMD。多年來一直是雙寡頭壟斷。保持這種雙寡頭壟斷的一個緣由是 x86 架構只在這兩家公司之間交叉許可，並且一般預編譯的代碼須要 x86 或 x86-64（也就是 AMD-64）架構。還有其餘因素，例如設計世界上最快的 CPU 是一件很艱難但也很昂貴的事情。

WebAssembly 是一種可以讓您在任何平臺上運行代碼的技術（之一）。若是它成爲下一個風口，硬件市場將變得商品化。應用編譯爲 WebAssembly，就能夠在任何東西上運行 - x86，ARM，RISC-V，SPARC。即使是操做系統市場也會商品化；您所須要的只是一個支持 WebAssembly 的瀏覽器，以便在硬件能夠運行時運行最苛刻的應用程序。

編者注：Second State 研發的專爲服務端優化的 WebAssembly 引擎 SSVM 已經能夠運行在高通驍龍芯片上。Github 連接：https://github.com/second-sta...

雲計算

但等等，還有更多。雲計算成爲IT經理辦公室的流行詞已有一段時間，WebAssembly 能夠直接迎合它。

WebAssembly 在安全沙箱中執行。能夠製做一個容器，它能夠在服務器上接受和執行 WebAssembly 模塊，而資源開銷很小。對於提供的每一個服務，無需在虛擬機上運行完整的操做系統。託管提供商只提供對能夠上傳代碼的WebAssembly 容器的訪問權限。它能夠是一個原始容器，接收 socket 並解析本身的 HTTP 鏈接，也能夠是一個完整的 Web 服務容器，其中 WebAssembly 模塊只須要處理預解析的HTTP請求。

這還不存在。若是有人想變得富有，那麼能夠考慮這個想法。

編者注：目前已經有人正在實現這個想法，Byte Alliance 計劃將WebAssembly 帶到瀏覽器以外，Second State 已經發布了爲服務端設計的WebAssembly 引擎開發者預覽版。

不是雲計算

WebAssembly 足以取代 PC 上本地安裝的大多數應用程序。咱們已經使用 WebGL（又名OpenGL ES 2.0）移植了遊戲。我預測不久以後，受益於WebAssembly，像 LibreOffice 這樣的大型應用能夠直接從網站上得到，而無需安裝。

在這種狀況下，在本地安裝應用沒什麼意義。本地安裝的應用和 WebAssembly 應用之間幾乎沒有區別。WebAssembly 應用已經可使用屏幕，鍵盤和鼠標進行交互。它能夠在 2D 或 OpenGL 中進行圖形處理，並使用硬件對視頻流進行解碼。能夠播放和錄製聲音。能夠訪問網絡攝像頭。可使用 WebSockets。可使用 IndexedDB 存儲大量數據在本地磁盤上。這些已是 Web 瀏覽器中的標準功能，而且均可以使用 JavaScript 向 WebAssembly 暴露。

目前惟一困難的地方是 WebAssembly 沒法訪問本地文件系統。好吧，能夠經過 HTML 使用文件上傳對話，但這不算。最終，總會有人爲此建立 API，並可能稱之爲 「WASI」。

「從互聯網上運行應用程序！？胡說八道！「，你說。好吧，這是使用 Qt 和 WebAssembly 實現的文本編輯器 （以及更多）。

這是一個簡單的例子。複雜的例子是在 WebBrowser 中運行的 Adobe Premier Pro 或 Blender。或者考慮像 Steam 遊戲同樣能夠直接從網絡上運行。這聽起來像小說，但從技術上說這並不是不能發生。

它會來的。

讓咱們裸奔！

目前，WebAssembly 在包含 HTML 和 Javascript 包裝器的環境中執行。爲何不脫掉這些？有了 WebAssembly，爲何還要在瀏覽器中包含 HTML 渲染器和 JavaScript 引擎？

經過爲全部服務提供標準化 API，這些服務一般是 Web 瀏覽器提供的，能夠建立裸 WebAssembly。就是沒有 HTML和 Javascript 包裝來管理的 WebAssembly。訪問的網頁是 .wasm 文件，瀏覽器會抓取並運行該文件。瀏覽器爲WebAssembly 模塊提供畫布，事件處理程序以及對瀏覽器提供的全部服務的訪問。

這目前還不存在。若是如今使用 Web 瀏覽器直接訪問 .wasm 文件，它會詢問是否要下載它。我假設將設計所需的 API 並使其工做。

結果是 Web 能夠發展。網站再也不侷限於 HTML，CSS 和 Javascript。能夠建立全新的文檔描述語言。能夠發明全新的佈局引擎。並且，對於像我這樣的 polyglots 最相關，咱們能夠選擇任何編程語言來實如今線服務。

可訪問性

但我聽到了強烈抗議！可訪問性怎麼樣？？搜索引擎怎麼辦？

好吧，我尚未一個好的答案。但我能夠想象幾種技術解決方案。

一個解決方案是咱們保留內容和表現的分離。內容以標準化格式編寫，例如 HTML。演示文稿由 WebAssembly 應用管理，該應用能夠獲取並顯示內容。這容許網頁設計師使用想要的任何技術進行任意演示 - 不須要 CSS，而搜索引擎和須要不一樣類型的可訪問性的用戶仍然能夠訪問內容。

請記住，許多 WebAssembly 應用並非能夠經過文本訪問的，例如遊戲和許多應用。盲人不會從圖像編輯器中得到太多好處。

另外一個解決方案是發明一個 API，它能夠做爲 WebAssembly 模塊，來提供想在屏幕上呈現的 DOM，供屏幕閱讀器或搜索引擎使用。基本上會有兩種表示形式：一種是在圖形畫布上，另外一種是產生結構化文本輸出。

第三種解決方案是使用屏幕閱讀器或搜索引擎可使用的元數據來加強畫布。執行 WebAssembly 並在畫布上呈現內容，其中包含描述渲染內容的額外元數據。例如，該元數據將包括屏幕上的區域是不是菜單以及存在哪些選項，或者區域是否想要文本輸入，以及屏幕上的區域的天然排序（也稱爲標籤順序）是什麼。基本上，曾經在 HTML 中描述的內容如今被描述爲具備元數據的畫布區域。一樣，這只是一個想法，它可能在實踐中很糟糕。

多是什麼

1995年，Sun Microsystems 發佈了 Java，帶有 Java applets 和大量的宣傳。有史以來第一次，網頁能夠作一些比<marquee>和 GIF 動畫更有趣的事情。開發人員可使應用徹底在用戶的 Web 瀏覽器中運行。它們沒有集成到瀏覽器中，而是實現爲繁重的插件，須要安裝整個 JVM。1995年，這不是一個小的安裝。applets 也須要一段時間來加載並使用大量內存。咱們如今憑藉大量內存，這再也不是一個問題，但在 Java 生命的第一個十年裏，它讓體驗變得使人厭煩。

applets 也不可靠。沒法保證它們會運行，尤爲是在用戶使用 Microsoft 的實現時。他們也不安全，這是棺材裏的最後一顆釘子。

以 JVM 爲榮，其餘語言最終演變爲在 JVM 上運行。但如今，那艘船航行了。

FutureSplash / Macromedia / Adobe Flash 也是一個競爭者，可是是專有的，具備專有工具集和專有語言的專有格式。我讀到他們確實在2009年開啓了文件格式。最終從瀏覽器中刪除了支持，由於它存在安全風險。

這裏的結論是，若是但願您的技術存在於每一個人的機器上，那麼安全性就須要正視。我真誠地但願 WebAssembly 做爲標準對安全問題作出很好的反應。

須要什麼？

WebAssembly 仍處於初期階段。它目前能很好的運行代碼，而規範版本是 1.0，二進制格式定型。目前正在開展SIMD 指令支持。經過 Web Workers 進行多線程處理也正在進行中。

工具可用，並將在將來幾年不斷改進。瀏覽器已經讓你窺視 WebAssembly 文件。至少 Firefox 容許查看WebAssembly 字節碼，設置斷點並查看調用堆棧。我據說瀏覽器也有 profiling 支持。

語言支持包括一套不錯的語言集合–C，C++和Rust是一流的公民。C＃，Go和Lua顯然有穩定的支持。Python，Scala，Ruby，Java和Typescript都有實驗性支持。這多是一個傲慢的陳述，但我真的相信任何想要在21世紀存在的語言都須要可以在 WebAssembly 上編譯或運行。

在訪問外部設備的 API 支持方面，我所知道的惟一可用於裸 WebAssembly 的 API 是 WASI，它容許文件和流訪問等核心功能，容許 WebAssembly 在瀏覽器外運行。不然，任何訪問外部世界的 API 都須要在瀏覽器中的 Javascript 中實現。除了本地機器上的文件訪問，打印機訪問和其餘新穎的硬件訪問（例如非標準藍牙或USB設備）以外，應用所需的一切幾乎均可以知足。「裸WebAssembly」並非它成功的必要條件; 它只是一個小的優化，不須要瀏覽器包含對 HTML，CSS 或 Javascript 的支持。

我不肯定在桌面環境中讓 WebAssembly 成爲一等公民須要什麼。須要良好的複製和粘貼支持，拖放支持，本地化和國際化，窗口管理事件以及建立通知的功能。也許這些已經能夠從網絡瀏覽器中得到; 我常常驚訝與已經可能的事情。

引起爆炸的火花是建立容許現有應用移植的環境。若是創造了「用於 WebAssembly 的 Linux 子系統」，那麼能夠將大量現有的開源軟件移植到 WebAssembly 上。它須要模擬一個文件系統 - 能夠經過將文件系統的全部只讀部分都緩存爲 HTTP 請求來完成，而且全部可寫部分均可以在內存中，遠程存儲或使用瀏覽器能夠提供的任何文件訪問。圖形支持能夠經過移植 X11 或 Wayland 的實現來使用 WebGL（我理解已經做爲 AIGLX 存在？）。

一些 SDL 遊戲已經被移植到 WebAssembly - 最着名的是官方演示。

一旦 JVM 在 WebAssembly 中運行，就能夠在瀏覽器中運行大量的 Java 軟件。一樣適用於其餘虛擬機和使用它們的語言。

與 Windows 軟件的巨大世界同樣，我沒有答案。WINE 和 ReactOS 都須要底層的 x86 或 x86-64 機器，因此惟一的選擇是獲取源代碼並移植它，或者使用 x86 模擬器。

尾聲

WebAssembly 即將到來。
它來得很慢，但如今全部的部分均可以在你正在使用的瀏覽器上使用。如今咱們等待構建用於從各類編程語言中定位 WebAssembly 的基礎設施。一旦構建完成，咱們將擺脫 HTML，CSS 和 Javascript 的束縛。

相關閱讀

• 爲何說軟件服務的將來必然是WebAssembly？
• 區塊鏈、硬件與面向服務的架構，WASM 即將迎來大爆發?