自從WebAssembly標準發布以及各大瀏覽器完成對其默認支持之后，WebAssembly成為前端熱門話題。在WebAssembly之前，類似的前端二進制標準有火狐主導的asm.js和Chrome主導的PNaCl。二者均用于將后端C/C++代碼用于前端，作為它們折中方案，WebAssembly標準更偏向于asm.js的實現。Chrome在支持了WebAssembly標準之后，宣布將放棄對PNaCl的支持。

作為前端標準，PNaCl在創立之初就有其先天不足。在設計上，PNaCl代碼和前端代碼（Javascript、HTML等）高度獨立，并且PNaCl代碼運行在獨立進程中，這使得PNaCl代碼和頁面代碼交互成本非常高（需要通過IPC方式）。另外，處于安全考慮，PNaCl進程運行在沙箱環境中，Chrome為此定義了一套API，稱為：Pepper。Pepper定義的API中，有許多和現行Web標準重復。

更加嚴重的問題是，不論是Pepper還是PNaCl，都沒有明確的二進制代碼規范。因此非Chrome瀏覽器如果要兼容PNaCl插件，要么反向工程Pepper來自己實現一套接口實現，要么從Chromium工程中導入其中的實現代碼。無論哪種方式，都需要和Google的修改同步。這對于開發者來說是不可接受的。

相反，asm.js實現方式從一開始就盡量貼近前端開發和已有前端標準。asm.js用Javascript數組來表示內存，并將C/C++代碼編譯成Javascript以操作這個數組。這種實現方式相比PNaCl有一個很大的優勢：所有代碼在同一個JS虛擬機中運行，可以方便的和其他Javascript代碼、DOM進行交互。另外，這樣的實現沒有引入新的API，因此文檔相關的工作也比較少。

綜上所述，WebAssembly標準最終和asm.js比較接近，它實現在JS虛擬機中，可以和頁面Javascript之間方便的進行調用。WebAssembly標準除了新增加載和鏈接WebAssembly代碼相關的API之外，沒有定義新的平臺相關API。和asm.js不同的是，WebAssembly完整定義了二進制代碼規范，相關規范文檔已經完成。

當然，Google和其他團隊在WebAssembly標準的制定上也功不可沒。針對PNaCl插件，Google已經發布了遷移文檔。可以說，WebAssembly標準的發布，真正的贏家是開發者！

原文地址：http://www.infoq.com/cn/news/2017/06/WebAssembly-fire-fox-win

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的WebAssembly，开发者赢了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。