InfoQ|WebAssembly如何演进成为“浏览器第二编程语言”？( 四 )

其次， asm.js 实质上是一种较为 hack 的实现方式，类似|0的类型标注不具有可读性，同时拓展 asm.js 也变得越来越复杂且不可靠：随着 asm.js 想要更加接近于 Native 的执行性能，不免会对诸多 Math 函数（例如 Math.imul 及 Math.fround 等）进行拓展和改写。从长远来看，这对 TC39 标准的制定并不友好，同时 asm.js 自身的相关实现（例如 memory growth 等）也遭遇了非常多的问题，导致 asm.js 标准被迫不断修订。 “The hacks had a cost” ，我们需要一个全新的技术来解决 asm.js 所遇到的这些问题。合作共赢 - WebAssembly在 2013 年， NaCl/PNaCl 与 asm.js/Emscripten 形成了不同路线发展的竞争态势，但与此同时， Google 及 Mozilla 也在工具及虚拟机层面加强了许多合作，其中包括：

由 Google 的 JF Bastien 牵头，每月 Google 和 Mozilla 工具团队之间开展交流会；
Emscripten 和 PNaCl 开始共享部分代码，包括 Legalization Passes、le32 triple 等；
尝试将 NaCl 应用通过 Emscripten 编译，并开源 Pepper.js；
Google 及 Mozilla 共同向 asm.js 贡献代码，并规划未来 Native Code 在 Web 上的合理方案；
就 WebAssembly 前身“WebAsm”进行标准和方案的讨论；

最终在 2015 年的 4 月 1 号， “WebAssembly”击败了“WebAsm”、“WebMachine”和其它名称，在 Google 和 Mozilla 的团队交流邮件中被确定使用。至 2015 年 6 月 17 号，两方就 WebAssembly 的标准化工作达成一致，并搭建了 WebAssembly 官网开始对外宣传。 WebAssembly 的设计汲取了 NaCl 与 asm.js 两者的优点：

WebAssembly 并不依赖于 JavaScript ，与 NaCl/PNaCl 一样，它基于二进制格式，能够被快速解析；
与 asm.js 一样，依靠 Emscripten 等工具链提供的 API ，它以非常自然的方式直接操作 Web APIs ，而不用像 PNaCl 一样需要处理与 JavaScript 之间的通信；
WebAssembly 依赖于 LLVM IR 并使用独立的 VM 环境，因此其它语言 / 平台能够以较低成本接入，同时能够且易于被持续优化至接近 Native 的性能；

目前各大主流浏览器已经完全实现了 WebAssembly 的 MVP 版本，并将其接纳为“浏览器的第二语言” 。依靠优秀的设计， WebAssembly 也从浏览器平台走向更多平台， WASI（WebAssembly System Interface）将为 WebAssembly 提供更多的可能性。随着 WebAssembly 相关标准逐渐确定和完善， WebAssembly 技术的应用领域将会越来越广。
小结本文从 JavaScript 开始，介绍了 NaCl/PNaCl 以及 asm.js 技术方案的优缺点。通过简单回顾 WebAssembly 相关历史背景，我们能更好地够理解 WebAssembly 技术的演变过程及其适用场景。在后面的文章中，我们将基于 Emscripten 工具链继续探讨 WebAssembly ，并通过具体的实例介绍 WebAssembly 应用的基本方法和相关实现。
致谢感谢 Emscripten 核心作者 Alon Zakai 在我写作此篇文章时对邮件所提问题的耐心解答和帮助，如此才使得我能够更全面、详细及正确地还原有关 WebAssembly 的技术演变历程。
作者介绍：赵洋， Coupang 资深全栈工程师，曾任百度、腾讯、全民直播前端工程师， Modern Web/GMTC/FDCon 等多个会议讲师，编写了多个 WebAssembly 项目实践，目前正在尝试 WebAssembly 在图形相关领域的实践。
InfoQ 读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加 InfoQ 小助手，回复关键字“进群”申请入群。大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！