本周發布的 Firefox 52 加入了對 WebAssembly 的支持，成為第一個支持 WebAssembly 標准的瀏覽器，而其它瀏覽器如 Chrome 57、Safari 和 Edge 也都會陸續支持 WebAssembly。WebAssembly 源於Mozilla 發起的 Asm.js 項目，設計補充而非取代 JavaScript， 它是一個二進制格式，容易翻譯到原生代碼，本地解碼速度比 JS 解析快得多，讓高性能的 Web 應用在瀏覽器上運行成為可能，比如視頻游戲、計算機輔助設計、視頻和圖像編輯、科學可視化等等。未來，現有的生產力應用和 JavaScript 框架都有可能使用 WebAssembly，能顯著降低加載速度，同時改進運行性能。開發者可以將針對 CPU 密集計算的 WebAssembly 庫整合到現有的 Web 應用中。
你聽說過 WebAssembly 嗎？這是由 Google , Microsoft , Mozilla ， Apple 等幾家大公司合作發起的一個關於 面向Web的通用二進制和文本格式 的項目。 現在就讓我們來看看WebAssembly到底是個啥？為什么它的出現和未來的發展跟我們每個人都息息相關，即使你並不是一個程序猿/媛~
至少在某種程度上，它將改變Web生態。
JavaScript–Web世界的匯編語言
我們有許多面向Web應用的開發規范，這些設計優良的規范讓Web開發者們的工作變得更加的簡單。我們很難想象自己所創建和網站或應用沒有任何規則、編程語言、框架和開發理念可以遵循。
而將所有這些事情組合到一起的Web規范有一個眾所周知的名字： JavaScript ！
JavaScript基本上已經成為了Web平台的標准開發語言。而隨着越來越多的軟件成為了Web應用，JavaScript更是獲得了極大的發展。
但在過去幾年，我們看到越來越多的項目問世，它們試圖通過開發編譯程序，將其他語言代碼轉化為 JavaScript，以此讓開發者克服 JavaScript自身存在的一些短板。其中一些項目專注於給編程語言增加新的功能，比如微軟的 TypeScript 和Google的 Dart ，或是加快 JavaScript的執行速度，例如 Mozilla 的 asm.js 項目和Google的 PNaCI 。
在默認環境下，JavaScript文檔其實就是簡單的文本文件，先是從服務器下載，然后由瀏覽器中的 JavaScript引擎解析並編譯。用戶可以通過Ajax技術在瀏覽網頁時與服務器進行通信。
在瀏覽器端目前是使用JavaScript來實現與用戶進行動態交互等功能，雖然很多JavaScript框架都致力於性能優化，但是一套基於字節碼的系統仍然會有更快更好的性能表現。
所以，WebAssembly到底是個什么鬼？
WebAssembly是一種新的字節碼格式。它的縮寫是".wasm"， .wasm 為文件名后綴，是一種新的底層安全的二進制語法。。它被定義為“精簡、加載時間短的格式和執行模型”，並且被設計為Web 多編程語言目標文件格式。 這意味着瀏覽器端的性能會得到極大提升，它也使得我們能夠實現一個底層構建模塊的集合，例如，強類型和塊級作用域。（原文： And it gives us access to a set of low level building blocks, such as a range of types and operations. 這句話我實在不知如何翻譯。。。） 不過別搞錯了，這並不意味着WebAssmbly是為了取代 JavaScript而生喲~ 就像Bjarne Stroustup說的：“JS會活得很好，因為世界上只有兩種類型的語言：一類語言被人們不斷的地吐槽，而另一類語言壓根兒沒人用！”而 Eric Elliott 認為：“最好不要把WebAssembly僅僅當做一門編程語言，實際上它更像是一個編譯器。”
從asm.js到WebAssembly？
asm.js 是一個JavaScript的一個嚴格的子集，可以被用來作為一個底層的、高效的編譯器目標語言。asm.js提供了一個類似於C/C++虛擬機的抽象實現，包括一個可有效負載和存儲的大型二進制堆、整型和浮點運算、高階函數定義、函數指針等。
asm.js的思想是使用它所規定的方法來編寫JavaScript代碼，支持asm.js的引擎會將代碼轉變為十分高效的機器碼。如果你是將C++代碼編譯為asm.js，將在瀏覽器端獲得極大的性能提升。
webassembly相較於asm.js的優勢主要是涉及到性能方面。根據 WebAssembly FAQ 的描述：在移動設備上，對於很大的代碼庫，asm.js僅僅解析就需要花費20-40秒，而 實驗 顯示WebAssembly的加載速度比asm.js快了20倍，這主要是因為相比解析 asm.js 代碼，JavaScript引擎破譯二進制格式的速度要快得多。
這玩意兒到底好在哪？
你很可能會問：“為啥所有人都在談論WebAssembly？”這是因為WebAssembly對於JS來說絕對是一個巨大的改進，但我們常常會問自己：“這樣，就夠了嗎？”當然不是，WebAssembly對於瀏覽器來說也有着非同一般的意義。 支持WebAssembly的瀏覽器可以識別二進制格式的文本，它有能力編譯比JS文本小得多的二進制包。 這將給web應用帶來類似與本地應用的性能體驗！這四不四聽起來很棒啊？！如果瀏覽器不得不解析完整的JS代碼，這將會耗去好多時間（特別是在移動平台上），而瀏覽器對WebAssembly格式的解碼速度顯然要快得多得多得多：） 下面獻上JS作者BE大神的演講視頻地址（油管，需翻牆）： Brendan Eich on JavaScript Taking Both the High and Low Roads - O'Reilly Fluent 2014
都有誰入了WebAssembly的坑？
包括Google, Microsoft，Mozilla只是這一長串名單中的少數幾家公司。項目帶頭人們發起了 WebAssembly Community Group 這一社區，這個團隊的願景是“在一種新的，輕量的web編碼格式的基礎上，促進瀏覽器廠商們的合作.” 不過，WebAssembly項目還只是剛剛啟動，雖然它有一個美妙的開頭，但在WebAssembly成為一個大眾認可的web標准之前，它還有很長的路要走。
為啥這玩意會影響每一個web開發者
因為webassembly讓開發者有能力選擇之前那些不能用來開發web應用的語言來進行web開發，或者他們也可以繼續使用簡單易用的JavaScript！ W3C WebAssembly Community group 給出了一些WebAssembly的用例，它們展示了WebAssembly如何使得web開發者更加輕松的工作:
- 一些執行效率更高的語言可以被編譯成在Web平台上執行的代碼。
- 提供了在瀏覽器端的開發者工具
- 更加快捷的企業級應用客戶端(例如：數據庫)
WebAssembly的用途很多。舉幾個栗子：WebAssembly可以被嵌入到已經開發好的JavaScript/HTML代碼中;或者某款應用的主要框架可以使用 WebAssembly 模塊（如動畫、可視化和壓縮等），而用戶界面仍然可以主要使用 JavaScript/HTML語言編寫。
精簡的代碼，更好的性能，更少的bug？
據WebAssembly的開發團隊描述，使用WebAssembly意味着更少的原代碼。與asm.js相比，它減少了大約25%的代碼量。雖然這僅僅是一個原型。 現在你可能很想知道如何獲取關於WebAssembly的最新進展，下面這些資源將會對你很有幫助：
- GitHub page of WebAssembly
- Design documentation of WebAssembly
- W3C WebAssembly Community Group
- What is WebAssembly by Eric Elliott （這篇文章也說得很棒，有空也可以翻譯一下！）
粗略翻譯, 推薦看原文
https://auth0.com/blog/2015/10/14/7-things-you-should-know-about-web-assembly/
了解 WebAssembly, 了解 Web 的將來
介紹
如果你不熟悉 WebAssembly 后面的概念, 可以讀一下:
ArsTechnica 的 Peter Bright 寫的優秀的論文,
或者是 Brendan Eich 在他的個人博客上寫的公告文章
考慮到本文的目標, 這里加上個簡短的術語表:
-
源碼(Source code): 開發者寫的.
-
編譯器(Compiler): 一個應用程序, 用於把源碼轉換為匯編,字節碼或者機器碼 (任何其他的應用程序或者硬件可以運行的)
-
匯編(Assembly): 低級的類似源碼的語言, 針對特定機器或特定應用程序
-
字節碼(Bytecode): 低級的二進制的代碼形式, 可以被其他應用程序執行
-
機器碼(Machine code): 代碼的二進制形式, 可以由硬件直接執行
WebAssembly 的目標是 Web 的字節碼. 未來的開發者會這樣使用 WebAssembly:
-
開發一個應用(源碼用任何可以編譯到 WebAssembly 的語言)
-
用編譯器把源碼轉換到 WebAssembly 字節碼(可能只要的話轉化成匯編)
-
在瀏覽器加載字節碼並執行
真相 1: WebAssembly 不是 JavaScript 的末日
已經說過的再說一次: JavaScript 依然會繼續
得益於 Web 平台的增長, JavaScript 已經成為開發者和工具鏈的通用語言
WebAssembly 不會改變這一點
WebAssembly 想要替代的是目前 JavaScript 被強行用來占據的地方:
可以用作編譯目標的底層的代碼表示形式
As more and more languages and platforms begin to target the web,
隨着越來越多語言和平台以 Web 為目標, JavaScript 有着更多的壓力
瀏覽器提供商為此盡可能加入缺失的功能
其中一些功能在已經很復雜的 JavaScript 語義當中不能運作地很好
WebAssembly 就是為這個問題提供答案:
-
它從一開始就被設計為編譯目標
-
它將得到所有主流瀏覽器提供商的支持
-
它可以根據需要任意地偏離 JavaScript 原有的語義
WebAssembly 對於 Web 來說是對 JavaScript 很有必要的補充
真相 2: WebAssembly 由 ASM.js 和 (P)NaCl 背后的團隊開發
如果你過去幾年跟進了 Web 的發展你就知道 WebAssembly 目標很有難度:
為不能輕易映射到 JavaScript 的語言提供一套統一的編譯目標.
不僅僅從技術方面來說目標很艱難, 而且從標准方面來說也是困難的
Web 並不是由單一的提供商控制, 每一個改變都一定是聯合的努力
幸運的是, WebAssembly 背后的團隊知道這一點.
在 Mozilla, 一群專家開發者嘗試通過 ASM.js 的形式提供答案:
用一個套 JavaScript 的子集作為編譯目標
另一方面, Google 致力於 Native Client(NaCl) 和 Portable Native Client(PNaCl):
一套基於 LLVM 的 Web 的二進制格式
盡管每個方案某種程度上取得了效果, 但他們沒有能的方所有問題提供滿意答案
基於這個經驗 WebAssembly 才浮現出來: 聯合努力來提供跨瀏覽器的編譯目標
WebAssembly 的未來看起來一篇光明
Fact 3: WebAssembly 會向后兼容
Web 的一個基礎特性就是向后兼容性, WebAssembly 也不例外:
對於就瀏覽器將會有一套 polyfill. 而且, 它的原型已經有了
你可以在這里和這里看到它們已經在使用
Fact 4: WebAssembly 看起來不像 CPU 匯編
當聽到"匯編"這個詞你也許馬上在腦子里聽到"可讀性差"這句話
幸運的是, WebAssembly 不是這樣. 相對於其他底層代碼表示形式,
或者大多數的二進制碼, WebAssembly 描述的是抽象語法樹(AST)
是的, WebAssembly 提供了高級的結構, 比如循環和分支
意味着可以直接寫 WebAssembly, 或者反編譯二進制文件
從而得到可讀性比較好的 opcodes 或者指令
你可能會想"變量名怎么辦?" WebAssembly 將支持編譯后文件增加調試信息
這里舉了例子 WebAssembly 的文本形式看起來怎么樣例子使用了 S 表達式(一種輕量級的 AST 表示):
;; Iterative factorial named
(func $fac-iter (param $n i64) (result i64) (local $i i64) (local $res i64) (set_local $i (get_local $n)) (set_local $res (i64.const 1)) (label $done (loop (if (i64.eq (get_local $i) (i64.const 0)) (break $done) (block (set_local $res (i64.mul (get_local $i) (get_local $res))) (set_local $i (i64.sub (get_local $i) (i64.const 1))) ) ) ) ) (return (get_local $res)) )這里看完整的例子
那么, S 表達式是最終的格式嗎? 不是的, 目前沒有 WebAssembly 的官方版本還有另一個例子, 完全不用的語法, 你可能會更熟悉
export func main() i32 {
storeI32(temp, 0); var i i32 = 0; done: while (i < 10) { i = i + 1; if (i >= 7) { break done; } } return (i + ifelse(0, 1, 2) * 2) * loadI32(temp) + loadI32(scale); }可以在這里看到
真相 5: WebAssembly 會擴展出 JavaScript 所沒有的功能
WebAssembly 初步的實現目標是等同 ASM.js 的功能.
也就是說, 能用 ASM.js 做的, 等 WebAssembly 推出之后你也能做(做得更好)
第一個版本的可以期待的一個改進是更好的加載時間
WebAssembly 的二進制版本比起 ASM.js 的文本格式可以更快地解析
所以即便是最初的版本, WebAssembly 也能顯示出改進
當前版本的 WebAssembly 叫做最小可行產品][mvp
將來的版本可以期待有這樣一些改進:
-
完整的線程支持
-
SIMD 類型和 intrinsics
-
零消耗的異常(棧審查和展開)
-
協成
-
動態鏈接
-
DOM 集成
-
集成垃圾回收
-
尾遞歸優化
-
多進程支持
其中一些功能用 JavaScript 甚至純粹的 ASM.js 都非常難實現
WebAssembly 基於這樣一些需求開發的, 作為優秀的語言平台
將支持上邊這些(以及更多的)功能
真相 6: Source Maps 幫助你在瀏覽器中輕松調試編譯后的代碼
編譯目標語言的一個不足是調試常常變得更難
如果你使用過現在編譯到 JavaScript 的任何語言,
你大概體會到過調試有多困難, 要靠記憶力把編譯結果映射到源碼
WebAssembly 的目標是成為其他語言優秀平台, 所以針對方案已經在做了
跟現今的本地編譯器很像, WebAssembly 將允許二進制中存在調試信息,
以及 Source Maps, 用來高所瀏覽器和調試工具怎么樣映射生成代碼到源碼
易於調試是作為 WebAssembly 規范的一部分的
Fact 7: 你不需要等到 WebAssembly 整個准備完成
盡管 WebAssembly 還在初期, 你已經能開始得到它將來能提供的好處了
在"真相 2"里我們提到. WebAssembly 來自於實現 ASM.js 和 NaCl 的多年經驗
兩套實現提供的所有的好處都將存在於 WebAssembly
如果你現在想要其中一些, 那么 ASM.js 就是優秀的一個方案
比如, Emscripten 現在能把你的代碼編譯到 ASM.js
如果你認為托付給 ASM.js 現在還不合適, 那么記着, WebAssembly 還只是初期
盡管這樣, WebAssembly 首先還是將具備 ASM.js 的功能作為第一個目標
所以不要害怕把將來賭在 ASM.js 上
WebAssembly 開發被作為當前的解決方案的一套升級路線,
所以, 雖然可以開始想想未來了, 但並不意味着 ASM.js 不會得到支持
Hack away!
題外話: WebAssembly 和已有的類庫
...
結論
過去幾年出現了大量的框架, 編譯器和其他類型的方案,
要把已有代碼編譯到 Web, 結果導致了社區當中的不少的失望
一方面, 不符合 JavaScript 語義和意識形態的功能在實施者的論壇里出現,
在 JavaScript 開發中當中激發了嚴重的問題
另一方面, 想使用已有代碼的開發者, 想使用最喜歡的語言和框架的開發者,
發現他們被攔在 Web 外面, 或者面臨着嚴重的調試門檻(以及其他問題)
即便現有方案如 ASM.js 和 PNaCl 做了大量工作減小這些操心,
然而到現在依然沒有合適的跨平台的解決方案. WebAssembly 想解決這個問題
恰當的, 跨平台的, 跨語言的編譯目標, 支持優秀的平台必要的所有功能
風險很高, 然而回報也非常豐厚. 背后的團隊也很清楚這一點
WebAssembly 是開發者們長久以來期待的想法的演進, 它也是將來