在2015.06.17， JavaScrpt之父Brendan Eich宣布了一个新项目：将新的底层原语（low level primitives）带入web中[1]。 这个新项目的博客文章已经有中文翻译，可参见[2]，但该中文翻译缺失了后半部分，同时我修订了其中一些不准确的文字，下面是中文翻译内容。

1. 今天的大新闻

JS 成为 Web 的 WebAssembly，这已经是老生常谈的话题。不过，JS 的语法可移植，JS还是很安全的机器语言。今天，我很高兴地宣布，在 WebAssembly 上可以进行跨浏览器的工作，这是web上安全代码的一种新型中间代表。

1.1 是什么

WebAssembly， 缩写为“wasm”，.wasm 为文件名后缀，是一种新的用于底层安全代码的二进制语法。它最初与 asm.js有相同的表达力，不过从长远来看，为了更好地向多种源代码级别编程语言的通用目标级别格式提供服务，WebAssembly会从 JS 的语义中分离。

为通过 JS 支持 wasm 的 polyfilling，wasm 和 asm 保持合理间隔是至关重要的。甚至随着 JS 和 asm.js的发展，都支持共享内存线程和SIMD也是相当重要的。更长期的发展后分开的功能可能有：零成本异常，动态链接，call/cc。是的，我们的目标是开发 Web 多种编程语言的目标文件格式。

1.2 为什么

asm.js 是很不错的，但是引擎一旦为它优化，解析器就会成为一个热锅 —— 会让移动设备变得很烫。传输压缩是必要的，而且能节省带宽，但是要在解析之前解压。第二个考虑因素：JS 存在一些尴尬的角落，甚至是在它的子集asm.js中。最后，一旦浏览器支持Native WebAssembly 语法，JS 和 wasm 就会分离，不会因为编译器使用了一些完全不同的编程语言就引入一些不安全或者不合适的特性到 JS 中。

请查看 FAQ 获取更多的细节信息。不，JS 在可见的未来里是不会消失的。是的，wasm 可以将JS从服务于两个主人的困境中解脱。这是一个双赢的计划。

1.3 怎么样

如果你使用 Emscripten，那么通过一个命令行标志，首先包含和目标是原型 polyfill, 就可以支持wasm。但是因为Native wasm 解码器出现在引擎顶部（请查看 V8 Native原型解码器），Emscripten 将会自动配置以获得最佳的效果。另一个原型：一个 JS AST 压缩器（编码器）。

随着WebAssembly走向成熟，这些原型将发展并跟踪draft规范的变更, 并接受更多开发人员的测试。除Emscripten之外的编译器, 以及除LLVM之外的编译器框架, 都将加入进来. 我期望所有的引擎都将支持更快的Native解码器。所有这些都将是最终达成一个公共的WebAssembly标准的财富。

1.4 谁在参与

一个 W3C Community Group（社区团体），WebAssembly CG 对所有人开放。正如你在 github 日志上看到的，WebAssembly 是 Google、Microsoft、Mozilla 和其他几家公司共同努力的结果。很抱歉，这项工作在一开始是通过github私有账号完成的，但这只是临时措施，用来使这几家大公司达成共识，从而能让这些公司有更长远的合作。

你可以看到，Google PNaCl 团队的 JF Bastien 只能勉强守住秘密（人们会说Web正在走向汇编）。

来自Google PNaCl 团队和 V8 团队的人员，来自 Microsoft 的核心人员，以及来自 Mozilla 的 asm.js 和 Emscripten的大师，这些人紧密地合作，直到每个人都看到了曙光，这真是一件振奋人心的事情。我在这里尤其要感谢 Google 的 JF Bastien，K. Gadd 和 Ben Titzer；Mozilla 的 Dan Gohman；来自 Microsoft 的 Abhijith Chatra 和 Michael Holman；asm.js 和 Emscripten 的牛人 Alon Zakai；做 JavaScriptCore/WebKit 的 Filip Pizlo；尤其是 asm.js/OdinMonkey 的主力 Luke Wagner。

2. 宏大蓝图

在计算历史上, 梦想有一个通用的, 中立于编程语言的中间体（intermediate）要追溯到Melvin Conway的UNCOL (1958, 同一年LISP语言诞生)之前[3]。我记得80年代有ANDF，70年代有U-something. 没有人希望遇到“N x M” 个编程语言与机器目标问题。

有时候在成功之前，我们必须围绕着命运之轮徘徊。神经元不是一次就发展好了的. 相信我，我发现值得开怀的是慢慢地JS (这是我之前未曾计划的!) 已经铺好了发展到WebAssembly的坦途. 是的，我们来了。

虽然LLVM不是唯一的生成wasm的编译器框架，但它已经对WebAssembly项目提供了非常大的便利, wasm的前辈Emscripten和PNaCl也是同样, 荣耀归于LLVM的创始人Chris Lattner和他的团队.

我了解的PNaCl成员都性情温和，但我认为有些人把我在HN（Hacker News?）的这些年看做是扮演卡珊德拉的角色到他们特洛伊之城（译者注：这句话语句不通顺呢？The PNaCl folks I know are good natured, but I think some are sore at me for playing Cassandra to their Troy over the years on HN.）。所以我想称赞他们解决了LLVN中大量不确定行为— 真正解决了各个级别的抽象，从C/C++规范一直到硬件。这些吃力不讨好的工作对WebAssembly是一个非常大的帮助，必须大多数都是确定性的而且定义完善以便用于互操作和安全。

底线：随着JS和wasm的共同发展, 几年后我相信所有的顶级浏览器都将支持能够真正通晓多种编程语言虚拟机的JS引擎。 我预测JS将持续发展，吸收越来越多的APIs和基于硬件的功能—但并非所有, wasm会承担这个重任.

我们再次看到通过许多小的碰撞，Web是如何获得成功的。

. 社区对发展路线达成一致, 通过

. 开发人员与实现人员不断测试每一个变化, 以及

. 通过可用的polyfill来支持那些老的已经部署的浏览器.

我通常在结尾处讲一个笑话：总是赌JS赢。我期待在wasm上继续工作，最终达到这并非一个笑话。

3. 参考资料

[1] From ASM.JS to WebAssembly, Brendan Eich, June 17th, 2015, https://brendaneich.com/2015/06/from-asm-js-to-webassembly/

[2] 从 ASM.JS 到 WebAssembly, 2015.06.19, http://www.oschina.net/news/63502/webassembly

[3] UNCOL, https://en.wikipedia.org/wiki/UNCOL

[4] Mac OS X 背后的故事（八）三好学生Chris Lattner的LLVM编译工具链, http://www.programmer.com.cn/9436/

[5] Chris Lattner：Swift 编程语言首席架构师, 2014.06.04, http://blog.jobbole.com/70139/