内容简介：WebAssembly，火狐赢了？
自从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标准的发布，真正的赢家是开发者！
感谢郭蕾对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- 前 Mozilla 高管爆料，谷歌一直在破坏火狐
- 火狐 Firefox 63 Nightly 更新支持 GPU 网页渲染
- Mozilla 优化 WebAssembly 和 JS 在火狐的调用
- Mozilla 优化 WebAssembly 和 JS 在火狐的调用
- 火狐浏览器66将减少内存占用，扩展插件性能加强
- 你追我赶，Opera 51 运行速度比量子火狐快 38％
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
