自从 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 ）关注我们。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论