現代Web開發的世界是令人興奮的發現：每年都會出現新技術，有望改變我們構建Web專案的方式。數十年來，JavaScript一直是Web互動的中堅力量，將Web開發從 “構建頁面並使頁面漂亮” 變為 “讓使用者說“哇！””。現在，出現了一個新的挑戰者-WebAssembly（簡稱為“ Wasm”）。

儘管許多Web開發人員對JavaScript 及其生態系統都非常滿意 ，但是相當多的同行經常批評JavaScript的缺點。多年來，開發人員社群為解決這些問題進行了許多嘗試-像React，Angular和Vue這樣的框架確實改善了JavaScript工作流程及其功能。

但是，WebAssembly可能具有重塑整個Web開發前景的潛力-就像1995年首次引入JavaScript一樣。在本文中，我們將探討WebAssembly是什麼，為什麼具有突破性以及如何使用。

什麼是WebAssembly？

WebAssembly以上關於重塑整個Web開發潛力的句子是一個嚴肅的主張，因此您的眉毛可能會懷疑地抬起頭來。像所有尖端技術一樣，WebAssembly通常會在Web開發人員之間引起混亂。為了更好地定義該術語，我們首先要解決WebAssembly實際上不是什麼：

WebAssembly不是一種程式語言。WebAssembly不僅是 “ Web中的C ++”。WebAssembly本身並不是Web技術，即使它被稱為 Web Assembly。

順便說一句，讓我們定義一下這個術語： WebAssembly是基於堆疊的虛擬機器的二進位制指令格式。 這個定義雖然簡短，但仍可為我們提供一些關鍵點：

它是一臺 虛擬機器 -一種處理器，其目的是在考慮可移植性的情況下將程式碼編譯為實際的體系結構。二進位制 指令通過兩個符號的系統表示。

WebAssembly架構

隨著Web開發的進展，對這種技術的需求成比例增長：越來越多的Web開發人員需要一種可以完成工作的工具，同時還要滿足許多要求：

快速： 比JavaScript更快，並且（理想情況下）與原生代碼相當。安全： 不得引入新漏洞。跨平臺： 在各種桌上型電腦和移動作業系統上的效能均相同。零配置： 可以正常工作。開發就緒 （即提供/支援開發和除錯工具）。

儘管有很多技術試圖贏得這場比賽，但所有這些技術都失敗了-除了JavaScript。一些參賽者包括ActiveX，Flash，Google的Native Client和asm.js，但是由於WebAssembly是本文的重點，因此您可以得出結論，他們並沒有達到期望。

為什麼WebAssembly這麼重要？

程式語言雖然功能強大，但其真正潛力在於其生態系統。JavaScript是該論點的一個引人注目的例子：由於使用了npm之類的強大工具，它設法超越了“只是另一種程式語言”的地位。

但是，即使npm有時也無法提供您想要的答案。假設您正在尋找可以解決問題的庫，但是您只會找到用JavaScript以外的語言編寫的庫。在使用WebAssembly之前，您將不得不自己將該庫移植到JavaScript上-現在，您可以將其直接用於幾乎相同的功能。

我們已經確定WebAssembly承諾跨平臺（甚至包括瀏覽器）的統一二進位制格式。可以說，這是該技術最令人興奮的新穎之處，類似於瀏覽器即應用程式正規化的出現。

Wasm的發展重點之一是垃圾收集支援。引入該功能並提供對Web API的本機支援後，開發人員最終將能夠使用JavaScript以外的其他語言來建立Web應用程式-C，C ++，Go，Rust，Java，Python ...誰知道，甚至如果PHP實現了完整的功能，型別系統！

WebAssembly還提供可預測的效能-減少瀏覽器效能差異的能力。

WebAssembly與JavaScript

儘管開發人員社群通常心胸開闊，但有時很難抗拒再開始“ 我最喜歡的技術比您喜歡的技術更好！” 辯論。JavaScript和WebAssembly也不例外，因此一些Web開發人員試圖使這些技術看起來像是對立的力量。這是一個重要的要點： JS和WASM之間的關係是共生的，而不是對抗的。

在許多情況下，WebAssembly可以解決JavaScript的缺點：一個示例是將JavaScript用作編譯目標（例如，通過asm.js）。顯然，這是一個壞主意，因為與解析和編譯JavaScript有關的資源成本。但是，WebAssembly在這種情況下的效能要好得多-它的二進位制格式速度可以加快啟動和執行的速度。

通常，WebAssembly程式碼與JavaScript程式碼相比要輕一些，而它們始終具有相同的功能。另一方面，WebAssembly模組通常比較重，並且與JavaScript模組相比，更難拆分。

僅通過效能數字來比較這些技術是很誘人的，因此這是另一個有趣的發現： JavaScript和WebAssembly具有相同的峰值效能。 但是，僅僅因為效能提升（如果有）而選擇一種技術是另一種技術是短視的-還有很多其他因素在起作用。

但是，尼克·菲茨傑拉德（Nick Fitzgerald）在他最近的研究中使用Rust和WebAssembly氧化源地圖概述了一個警告 ：與JavaScript相比，WebAssembly提供的效能更加可預測，因為JavaScript可能會受到反優化的影響，該過程迫使JavaScript執行流向退回口譯員。

WebAssembly與JavaScript基準測試

可以通過以下方式實現影象旋轉功能來證明這種奇怪現象 canvas：讓使用者旋轉4K影象並在不同的瀏覽器下對其進行測試。以下是Google Chrome實驗室的發現：

瀏覽器1花費了400毫秒來旋轉影象。瀏覽器2花費了500毫秒。瀏覽器3耗時2.5秒。瀏覽器4用了8秒。

看看這些資料，很容易得出這樣的結論： “啊哈，瀏覽器4是不良工程的一個很好的例子！” 但是，我們需要記住，不同的瀏覽器進行了不同的優化，因此瀏覽器4不是Netscape Navigator v0。 7-它只是一個功能強大的瀏覽器。在其他情況下，也許瀏覽器1是最慢的瀏覽器。

如下圖所示，另一方面，在WebAssembly中重寫此程式碼已幫助這些瀏覽器獲得大致相同的效能，最重要的是，它們的效能變得可預測-任何開發團隊都會對此表示讚賞。我們還可以看到JavaScript和WebAssembly的最高效能確實是相等的。

使用語言的速度

我們還應該注意，JavaScript和WebAssembly在效能上的等同性將來可能會消失：WebAssembly將很快獲得對執行緒和simd（單個指令，多個數據的支援 ，這將使其勝過JavaScript）。

WebAssembly的缺點和警告

當然，WebAssembly不是靈丹妙藥，它的缺點之一與手動記憶體管理有關：但是，等等，這在許多語言中都是完全正常的功能！因此，它本身並不一定是缺點 。但是，對於某些JavaScript開發人員而言，當他們開始自己管理記憶體資源時，這可能是整個範例的轉變。

另一個警告：WebAssembly程式碼在瀏覽器中被沙箱化，這意味著其功能僅限於JavaScript級別。儘管如此，我們仍可以使用某些瀏覽器來模仿本地應用程式的功能。這是C ++功能過渡到WebAssembly和JavaScript的方式：

檔案系統→Cookie，LocalStorage，IndexedDB。網路→XHR，提取，WebSocket。隨機→Math.random（）。非同步→輪詢+ setTimeout（）。3D→畫布，WebGL。

WebAssembly學習資源

在本文的這一點上，WebAssembly終於發揮了魔力，您渴望開始學習它。這就是要注意的問題：您本身並不學習WebAssembly；相反，您將學習一種可以編譯為該語言的語言。Rust就是一個很好的例子，它還具有出色的入門 資源。

為了快速入門，您可以使用WasmFiddle- 顧名思義，它是一個程式碼遊樂場，它使您可以在不使用 防護服的情況下試驗WebAssembly。

結論

WebAssembly有望在我們開發Web應用程式的方式中引入模式轉變。在Google和Mozilla等網路巨頭的支援下，它的未來看起來更加光明。

減少 載入時間。提高 執行/計算速度。 在網路應用中使用 C / C ++程式碼。