出處：https://skyao.io/post/201905-why-webassembly-is-a-big-deal

為了方便閱讀，微信公眾號已按分類排版，後續的文章將在移動端首發，想學習WebAssembly相關知識，請關注我。

WebAssembly是一個每個程式設計師都應該關注的技術。它會變得更流行。它將取代JavaScript。它將取代HTML和CSS。它將取代手機應用。它將取代桌面應用。在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的瀏覽器，以便在硬體可以執行時執行最苛刻的應用程式。

雲端計算

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

WebAssembly在安全沙箱中執行。可以製作一個容器，它可以在伺服器上接受和執行WebAssembly模組，而資源開銷很小。對於提供的每個服務，無需在虛擬機器上執行完整的作業系統。託管提供商只提供對可以上傳程式碼的WebAssembly容器的訪問許可權。它可以是一個原始容器，接收socket並解析自己的HTTP連線，也可以是一個完整的Web 服務容器，其中WebAssembly模組只需要處理預解析的HTTP請求。

這還不存在。如果有人想變得富有，那麼可以考慮這個想法。

不是雲端計算

WebAssembly足以取代PC上本地安裝的大多數應用程式。我們已經使用WebGL（又名OpenGL ES 2.0）移植了遊戲。我預測不久之前，像LibreOffice這樣的大型應用可以直接從網站上獲得而無需使用WebAssembly進行安裝。

在這種情況下，在本地安裝應用沒什麼意義。本地安裝的應用和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和大量的宣傳。有史以來第一次，網頁可以做一些比``和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的束縛。