WebAssembly，火狐赢了？

前端

自从WebAssembly标准发布以及各大浏览器完成对其默认支持之后，WebAssembly成为前端热门话题。作为asm.js和PNaCl的折中方案，Chrome在支持了WebAssembly标准之后，宣布将放弃对PNaCl的支持。这意味着火狐在前端二进制代码标准制定上的胜利吗？

自从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标准的发布，真正的赢家是开发者！