如何评论浏览器最新的 WebAssembly 字节码技术？这个注定是一个长回答，像我这种不喜欢写字的人，看到这种问题，一般都会在回答和不回答之间纠结一个星期。
下面要讲的，其实是一个悲伤的故事。 Javascript ，也叫Ecma script, 是这家伙用了 10 天时间赶出来的。。  所以，各位程序猿们，如果你觉得老板 10 天要你们上线一个 App 是一个丧心病狂的事情，那么可以多想想这位哥。Youtube 上有位哥的采访，你可以听听大神当年的故事。 https://www.youtube.com/watch?v=IPxQ9kEaF8c 当然，码农和大神的区别在于：遇到这种事情，10 天以后码农死掉了，而大神成功了。 只是但凡这种极速上线的事情，都会留下一堆的坑，大神和码农的的区别，也就是水洼和天坑的区别。 这个是坑列表：
 好吧，异常后来加上去了。 如果故事到此为止，其实不算一个悲伤故事，大神 10 天时间完成预定目的，东西也发布了，市场反应也不错。 但是问题是，市场反应实在是太好了，好得 Javascript 一路窜红，红得各大浏览器厂商纷纷支持， 成为浏览器里面事实上的官方语言。 在这个过程中， 还顺手干掉了 VB script, 于是这个当初为 “非专业编程人员和设计师” 的解释型语言现在居然变成互联网上面最重要的语言之一，被用来做各种之前想也不敢想的东西，甚至还有人不顾死活的拿他来做WebOS. 于是这个时候，之前所有的小水洼都变成了天坑。之后很长段时间 JS 领域的发展史，都可以说是填坑史。 其中最大的一个坑，就是性能。 性能填坑阶段一 Javascript 一开始就是解释性语言，解释性语言的一大特点就是慢， 而网页应用越来越复杂，如果点个按钮要等几秒钟，那淘宝的秒杀就要变成10秒杀了。这个当然不能忍。 于是聪明的人类想到一个办法，虽然你是解释型语言，但是我可以偷偷的编译你啊。 这个也不需要让这帮 “非专业编程人员和设计师” 们知道， 我只要在程序运行前的一刹那，编译即将运行的代码就好。你看我机不机智。 于是 Google 在 2009 年在 V8 中引入了 JIT 技术 (Just in time compiling 江湖人称即时编译)。 有了这个buff, Javascript 瞬间提升了 20 － 40 倍的速度。直接导致一大波大型网页应用的出现。从此 Javascript 一骑绝尘， 飞黄腾。。呃， 好像哪里不对嘛？ 人类的性能的期望是无穷无尽的，JIT 的带来的性能提升很快就榨干了。实际上 JIT 有以下问题：
 JIT 看到这里， 觉得好开心， 马上把 add 编译成  可是你随后又干了这样一个事情  JIT 编译器的表情肯定是
 怎么办， 已经编译成机器码了啊。这种情况下，JIT 编译器只能推倒重来。JIT 带来的性能提升，有时候还没有这个重编的开销大。
于是，整体上 Javascript JIT 提高的性能到达的天花板还是不高的，虽然是提高了 20 - 50倍，那只是因为之前解释执行实在是太慢了。。 性能填坑阶段二。 既然 JIT 遇到的问题是类型不确定问题和有一些语言功能，比如异常，for in ， JIT 起来很麻烦， 我可不可以搞个方法让用户不去用这些功能，同时让他们把用的类型都标注出来啊。 按照这个思路， 催生了两种实现路径：
 加上一堆没有什么卵用提示 x 其实是个 int， 然后有一个能够识别这些符号的JS引擎，你就可以不用猜类型了哦， 事实上，由于有了类型，连传统的 AOT 都成为了可能 (Ahead of time, 不懂的话，想象一下，就是和 C/C++ 那种编译方式就好了）。如果你没有注意到，第二种的速度提升潜力比第一种要大非常多。因为第一种，无论如何，也是就是让JIT (即时编译) 快一点, 第二种那可直接就编译了啊 (AOT). 这个是 Asm.js 相对于 JIT 和原生的性能对比  同时大家有没后注意到，这个不是原生代码哦， 性能堪比原生代码， 安全性和传统 Javascript 完全一样。 (尼玛，你让插件们怎么活）。Web Assembly 就是第二种方式，说到底，Mozilla, Google, Microsoft, and Apple 觉得 Asm.js 这个方法有前途，想标准化一下，大家都能用。 有 了大佬们的支持，Web Assembly 比 asm.js 要激进很多。 Web Assembly 连标注 Js 这种事情都懒得做了，不是要 AOT 吗？ 我直接给字节码好不好？（后来改成 AST 树）。对于不支持 Web Assembly 的浏览器， 会有一段 Javascript 把 Web Assembly 重新翻译为 Javascript 运行， 这个技术叫 polyfill, HTML5 刚出来的时候很常用的一个技术。 使用 AST 的原因是因为 AST 比字节码更容易压缩，也更容易翻译。 不了解 AST 可以看下面这张图， 说明 Javascript 引擎的执行过程。 Javascript 先编译为 AST， 然后到 Bytecode. AST 的抽象程度比 Bytecode 要高一级。  总结来说， Web Assembly 的工作方式如下：  好处是：
======================================================================= 感谢@sapjax Gmail 不是 2009 发布的， 是2009脱离beta，原文中已经删除其引用。 ======================================================================= 更新： 哥已成功潜入 Webassembly 成员组，代表我大 Opera. 哇哈哈哈哈哈哈 On August 6, 2015, 8:09 UTC, fredrik luo became a participant in the WebAssembly Community Group. This person was nominated by Lars Erik Bolstad. Web技术的创新永不停歇。6月18日，由谷歌，微软和Mozilla工程团队以及部分Webkit项目的工程师联合开发的工程 WebAssembly终于面向所有开发者开放。WebAssembly的宗旨很容易理解：“一种全新的跨浏览器Web中间表示层安全代码，为未来浏览器 带来一种可执行的标准二进制数据格式，使得越来越多的开发者，不仅仅是JavaScript开发者，甚至是Rust,C#,Go语言的开发者，借助统一的 编译机制，预先将这些语言开发的逻辑编译为浏览器可以执行的二进制代码格式，以此提高Web内容的性能和表现能力，同时为更多语言的开发者提供一种为 Web开发内容的有效途径。” 我想就WebAssembly和我掌管的企业的技术研发线的整合思路做一些分享。 WebAssembly 项目的面世让Egret整个研发团队欣喜异常，Egret看到WebAssembly项目将为未来Web游戏和应用带来的巨大提升，以及这个跨语言和平台 的项目和Egret Runtime整合所带来的广阔前景。这里，我将通过简单易懂的方式来解释，白鹭将如何将WebAssembly项目带入一个实用场景的宏观路线图。在开 启这个路线图之前，请先容许用简短的话语为为何引入这个路线图的计划做一下铺垫。 2014年初，Egret决定用 TypeScript语言（JavaScrpt严格超集，遵循下一代ES6标准，微软开源项目）编写一款与众不同的HTML5 Web游戏引擎，这个产品的初衷就是允许开发者能够通过TypeScript语言，去编写更大型的，更复杂的，更具交互体验的HTML5移动游戏。选择 TypeScript语言作为Egret Engine的开发语言的决策计划，比2015年3月谷歌和微软联合决定AngularJS2.0项目使用TypeScript语言开发早了15个月. 2014 年9月 Egret在国内推出Egret Runtime，这个产品设计就是为了解决HTML5在现阶段的三个重要问题而出现的。性能，适配，访问系统能力。Egert Runtime全部针对Egret Engine的TS/JS API在Runtime层用C++/OpenGLES做了逐一映射，这就使得Egret开发者开发的HTML5游戏，可以借助Egret Runtime达到跟Native游戏和应用一样的体验和性能。最早，Egret Runtime在JS对象的传输和处理上定制了开源的项目SpiderMonkey。但是，SpiderMonkey实在太慢了，我们又在一个月内把这部 分的机制迁移到了一个由Egret团队深度定制的V8内核上。几个月后，Egret Runtime的整体大小是2.6MB（包括一个深层Hack的V8引擎），初始化Launcher大小为10KB. 而目前Egret Runtime的安装激活量，截止到2015年5月是1.23亿部移动设备，以目前的增长速度，Egret Runtime应该可以通过合作伙伴的超级App和操作系统预装超过4亿台设备。 2015年5月 Egret又针对移动领域提供了一套完全基于HTML5标准的互动移动应用框架Lark。这个框架将可以满足非游戏行业的Web前端开发者和设计师更快更 高效地创作属于他们自己的Web App，同时又可以借助Egret Runtime获得更强的系统访问能力和设备适配能力。 针对以上的几款引擎框架运行时产品（Egret工作流产品均未列在此），我们看到WebAssembly，我们决定把未来版本的Egret Engine和Runtime与WebAssembly很好的整合在一起，计划是这样的： 1. Egret未来将为Egret Wing等开发工具提供扩展支持，允许开发者编写的TypeScript，JavaScirpt,甚至C#,Go,Lua语言预编译为 WebAssembly的wasm格式，并针对wasm的二进制格式和WebP的素材资源打包为一个安全加密的runtime项目文件压缩包。这样，既解 决了HTML5游戏的性能问题，又解决了HTML5游戏的凸显的安全问题。 2. 下一代的Egret Runtime将会考虑把定制化的V8换为WebAssembly的运行时,Egret Runtime将直接借助WebAssembly的能力提供面向二进制格式码的执行能力，这将可以大幅度降低Egret Runtime的体积，以及减少JS映射到C的中间层数据转换的消耗，初步预计这样的架构改动，可以再次提升HTML5移动游戏的表现力和性能，使得H5 移动游戏的体验完全与编译型语言编写的Native应用相同 3. Egret Runtime与WebAssembly项目的集成，将为更多语言的开发者提供一个快速通过Egret Wing开发调试与Egret Runtime运行的高效巡回工作流。 附上一张理想环境下的下一代Egret Runtime的HighLevel架构图：  Web技术的世界核心精神是包容与开放，Egret在这里毫无保留的分享WebAssembly与Egret Runtime的整合路线图。希望更多的开发者能够投身Web技术开发领域，因为这里的创新永无止境。 另一篇文章的传送门，有些内容已经过时了，产品研发的计划永远赶不上变化。 如何看待 HTML5 开源游戏引擎 Egret，HTML5 游戏开发的前景如何？ - 手机游戏 “好了，广告也打完了，该回去把案子结了”。 |
|
|
