WebAssembly 的介绍

是下一代的浏览器目标语言……

你说是就是啦 我还说下一代浏览器语言是 php 呢

JS 统一前后端的梦想要破灭？

如果浏览器普遍支持 webasm ，其他语言也能编译成 webasm bytecode ，我估计就没人写 js 了吧。

@wizardforcel 我倒是感觉。。到了那时候。。写 js 的人。。已经非常得多了。。。具体参考 vb 。。。

@youxiachai 为何不能参考 ios ？ obj-c 到 swift ，大家都选了接受，而 swift1 和 2 差别也挺大的，大家也选择了拥抱变化。

除了 php 之外， js 恐怕是坑最多的语言，这样才有转型的动力。

而且都是前端，一个是移动一个是 web 。

@wizardforcel 听到 JS 是除 php 之外坑最多的语言， C++笑了……

大家是不是还没搞懂 WebAssembly 是啥…… WebAssembly 其实是二进制的 JS 而已啊…… JS 要在 JS 引擎上跑需要 JS->ByteCode(类似)->机器码 这样的流程，那直接塞 ByteCode 就又快又小，这就是 WebAssembly 了。

所以这其实是相当于 JVM/.net 一样的东西，但是最后无论是哪个还是最早的那个语言(java/C#)用的人最多。

顺便其实浏览器早就普遍支持 asm.js 了，其他语言早就可以编译成 JS, 最后也没见哪个语言真的动摇了 JS 的地位呢……

@wizardforcel 其实。。举 ios 这个案例。。其实跟这个差得挺远的。。不过。刚想回复你的时候。。楼下已经有人回复了。。其实 WebAssembly 本质是一堆 ast 文本（ https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6#.2dp2i8g8n ）。。然后干的事情好像汇编的样子。。实际上并不是真汇编。。就好比上面有人提到的 jvm 。。。

替代 JS 的各位
https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-trying-to-replace-javascript
https://github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-only-for-cc-programmers

web 开发只有 JS 的现状很好，没有必要整其他语言，只会让局面变混乱
webassembly 只是为了加速计算密集的模块

@wizardforcel JS 一直在变化，现在的情况下， web 只有 JS 一个语言，都已经这么混乱了，举个例子，如果现在 objective-c 那边有人出了一个 obj-c 2.0 ，你觉得会怎么样？
而且 iOS 开发的标准，只有苹果有发言权，哪怕 swift 不好用， bug 一堆，苹果依然能宣布 xcode x.0 工具链不支持 objective-c ，并且 AppStore 只接受 swift 开发的 app
web 的标准是大家一起维护的，如果连一个语言标准都无法维持了，那就真乱成一团了

@YuJianrong 我觉得拿 js 当中间语言的人，也就是写 ts 或者 coffee 的人，不算“真正使用” js 。

就好比你的程序最终要编译成汇编才能执行，你能说你用汇编写程序吗？

之前 js 地位不动摇是因为它是浏览器唯一指定的脚本语言。现在有 webasm 了。

@sagnitude

我不知道你有什么动机不接受类型安全，而且有 class 语法糖的 ts 。

唯一的问题就是考虑到兼容性，还是支持直接嵌入 js 文本这种方式，那么还是可能有人为了图省事，愿意按照老方法写 js ，因为 js 可以直接写，其他语言都需要编译。不过这也是没有办法的事，不兼容的话现有的页面就都没法正常显示了。

假设 js 和 ts 都需要编译成 webasm 才能运行，我相信只要是对技术有点追求的人都不会选择 js 吧。我是这个意思。

@wizardforcel 我的理由是：因为 js 一直在变化。 class ， import 都已经在 ES6 里出现并在浏览器中获得支持； ES7 连 int float 都有了

1. 像 coffeescript 或者 underscore 这种工具，只要对语言有利的，大家都会使用的功能， JS 就会整合进去
我写过一段时间的 coffeescript ，最终放弃了，因为下一代 JS 已经吸收了一些重要特性（语法上的）。

2. 而 TS 和 Coffee 不是编译成 webasm 去运行，而是转译成 javascript 去执行，引擎运行的依然是 javascript ，不是 webasm ，只是增加了一个运行和调用 webasm 功能的模块

3. 另外， webasm 设计目标是提供类似于 nodejs c++ extension 的功能，上面我贴的链接里也提到了，“让 javascript 代码 import C++模块像引入 javascript 模块一样方便”

4. 至于类型安全，我想了一下，首先我认为 JS 已经很慢了，加类型检查不好；另外，我不想在浏览器里写 java ， javascript 是动态的，写起来很灵活，我很享受这一点；况且，现在我可以选择 C++编写模块了，重载的功能不会也不应该使用 js 编写，作为一个粘合语言，还有什么地方需要类型安全呢？

@sagnitude

1. 的确。。 es6 和 ts 的区分度已经不大了。那么，如果 webasm 支持 python ，你更倾向用哪一个呢？

2. 之前由于没有 webasm ，也就没有字节码，这东西必然要编译成 js 。但是现在， webasm 的出现提供了其他语言直接编译成字节码的可能性。我相信微软为了扩大 ts 的影响力，一定会这么做。就算微软不做，三方的团队也会做出解决方案。

3. webasm 的设计目标？谷歌微软苹果都想在浏览器中运行自己家的语言，于是就推了个字节码，然后他们自己家的语言可以编译成字节码来运行。当然这种方案是兼容 js 的，因为 js 也能编译成字节码。

4. js 带上 jit 不慢。（当然也有部分情况比较慢）。

http://my.oschina.net/kaixindewo/blog/49956

@sagnitude 说真的， Objective-C 现在就是 2.0 ……

@wizardforcel 你还是没搞懂我在说什么。

我说其他语言早就可以编译成 JS ，说的不是 TS/CoffeeScript 这种方案，而是早就有的 emscripten 这种把 LLVM Bytecode 编译成 JS 的方案。

现在的 webasm 实现，其实也是一样用 emscripten 编译成二进制 JS ，和 emscripten 编译成 asm.js 格式的 JS 一模一样，提高的是传输大小和 parse 时间，也就是说如果你只是把几百 K 的 C++项目编译成 JS 来跑的话，没有 webasm 也是一样的（几百 K 的 JS 大小和 parse 时间不成问题），但好几年过去了我没见到这种方案有动摇 JS 地位的可能。

然而如果你要做的是几十 M 的大项目，确实上 webasm 能得到可观的提高，但问题是……你真的会把几十 M 的大项目用 web 方式来做么……再怎么提高，几十 M 的二进制包还是需要很长的时间才能载入的……

所以其实 webasm 一开始出现的时候我就觉得这东西意义不大的。

@wizardforcel 顺便再重复一下，“之前 js 地位不动摇是因为它是浏览器唯一指定的脚本语言。现在有 webasm 了。 ”——这个观点的错误在于 webasm 其实还是 JS ，只不过是二进制的 JS 而已，其他语言编译成 webasm 和编译成 asm.js 没有本质区别， webasm 带来的只有传输和 parse 的提升，没有在 feature 上有什么以前做不到现在能做到的改变……

@sagnitude 前端现状很好，只是表面上而已，看看前端技术变化就知道前端有多么糟糕了。前端混乱是因为 JS 设计上有问题，而且各大浏览器标准不统一，当然引入新的技术、语言肯定会在一定程度上增加混乱程度，技术过渡嘛

@YuJianrong
JS 发展到现在已经成了浏览器端的汇编，看看现在基本上主流语言都有所谓的 transpiler 将自身编译成 JS ，然而事实上 JS 并不能胜任这个职位：第一这是一门高级语言；第二这门语言设计上有太多的坑；第三运行性能很成问题。既然 JS 本身不能胜任，为什么不让浏览器真正支持"汇编"呢。如果其它语言能无痛转成浏览器能执行的"汇编"，也就没多大必要使用设计不好、用起来蛋疼的 JS 了。

TS 和 CS 转 JS 效果当然很不错，因为它们本身就是在 JS 基础之上构建的(ts/cs 编译器都是 js 写的)，但是你用其它语言的 transpiler 就会知道以 JS 为目标语言是多么痛苦了，生成代码庞大，语言自身的一些特性被阉割。 ES 的确在不断演化，变得也越来越好用，然而现在大家不也都是需要将 ES6/ES7 编译到 ES5 才敢往线上放么。 JS 是一门很高级的语言，不适合作为汇编使用，只有出来一个低级底层一点的语言，其它语言才可以无痛 compile/transpile 到这个目标语言。

没记错的话 asm.js 只是 js 的一个子集，而且似乎并不是一个标准， mozilla 最先搞的，其它厂商并不一定买帐，而 webassembly 则是各大浏览器厂商共同制定标准。

有了 webassembly 这种格式，以前可能需要十几兆甚至更大的 JS 才能实现的功能，以后经过编译优化可能只需要几百 k ，性能也会有很大提升，所以以前写 JS 不敢想象的东西和功能，以后 webassembly 就变得现实。

说这么多其实我并不是前端，也没写过几行 JS ，上面只是基于个人的一些认识，至于未来是否就是 webassembly 统一前端也只有时间能说明了

@tennix 前端环境现在已经很好了，至少我现在已经把 IE10 以下的兼容性代码都干掉了…之前想都不敢想

console 不存在、 JSON 不存在、 XHR 需要兼容各种类型、判断千奇百怪的 UA ，连 hasOwnProperty 都不能直接用， requestAnimationFrame 也是坑爹货，等等等等

而现在我开发已经不需要考虑这些了，相比之前简直太幸福了

@YuJianrong 现在 webasm 还在早期开发，所以还在用 emscripten 编译，并且现在已经提供了一种直接编译的方法

https://github.com/WebAssembly/binaryen#cc-source--webassembly-llvm-backend--s2wasm--webassembly

@YuJianrong

webasm 不是 js ，而是 webasm bytecode ，你也可以理解成 js bytecode 。就好比 java 和 java bytecode 一样，你能说这两个东西一样吗？单从长相上来说就不一样。如果你不懂编译和字节码这块，当我没说。

@tennix

同意。研究过逆向的人都知道， bytecode 实际上和高级语言是多句对一句的关系，语句之间的界限并不像汇编那样模糊。但是其效果就是比预处理（此处实话说真的不能叫编译）成 js 好的多。

@YuJianrong webasm 至少对我会有很大的帮助，之前我在做 webgl 的东西，发现载入速度的瓶颈在解 zip 、 parse json 、新建对象上，并且是秒级延迟（ 1M 大小的 3D 文件），解 zip 、 parse json 这种事情基本上是纯算法的， C++的 zip 库也才百 K 级别
我现在必须载入 1M 的 JSON ，再用 1~2 秒渲染到 webgl
如果用 webasm ，我可以载入一个 100K 的 webasm zip 库，然后 JSON 文件改成二进制文件，我写了一个简单的 3D 压缩到二进制的程序，可以把这个 JSON 压到 300K ，如果是 C++解析 zip 和 JSON ，解析时间也能大大缩小
不仅传输的数据变少了，渲染时间还变少了，简直没有理由不支持

@tennix 哎……我觉得既然不懂前端就不要这么强行回答吧……
[看看前端技术变化就知道前端有多么糟糕了] 我一直看前端技术变化怎么只觉得越来越好呢？变化快不是什么坏事，变化快说明前端受到越来越多的重视，所以有越来越多的人带着各种思想进入这个领域，难道你觉得一个技术要向 2011 年之前的 C++那样几乎毫无变化才是好技术吗（然而现在照样在剧烈变化）。

[第一这是一门高级语言；第二这门语言设计上有太多的坑；第三运行性能很成问题] JS 确实有坑，但要说多的话其实也不多，而且 es5, es6 之后就填了不少，总的来说完全够不上“太多”这样的定义，一开始学习踩上几个真不算什么。性能上现在 JIT 的 JS 距离原生语言也就一个数量级而已， asm.js 就在一个数量级以内了，说实话比起大多数语言（ python, ruby ）来说已经好多了。

[TS 和 CS 转 JS 效果当然很不错，因为它们本身就是在 JS 基础之上构建的(ts/cs 编译器都是 js 写的)] 说实话语言和它的编译器用什么来写其实一点关系都没有（而且其实 CS 编译器早期版本是用 ruby 写的，后期是 cs ； TS 编译器在一开始推出就是 TS 写的），其实编译器自举只是对编译器的一种验证而已，并不能说明任何事情……这两个语言和其他语言 compile to JS 方案的最大区别只是这两个语言设计上就为 JS 特性做了裁剪而已，其他语言编译出来比较恶心只是因为没有裁剪那就只有比较恶心的方式来模拟……

[只有出来一个低级底层一点的语言，其它语言才可以无痛 compile/transpile 到这个目标语言...没记错的话 asm.js 只是 js 的一个子集，而且似乎并不是一个标准] 首先 asm.js 当然是一个标准，虽然是 Mozzila 提出来的，最新的浏览器除了 Safari 外都对 asm.js 有优化支持，其次其实 Asm.js 就是你要的那个底层语言……其实 Webasm 只是 asm.js 的二进制版而已……

[有了 webassembly 这种格式，以前可能需要十几兆甚至更大的 JS 才能实现的功能，以后经过编译优化可能只需要几百 k ，性能也会有很大提升] 这个真的就是纯 YY 了，我上面已经说了其实 webasm 只是 asm.js 的二进制形式，大小其实不会有本质的变化，根据官方 FAQ 的数据，二进制形式的代码大小也有 asm.js 的 1/3 大小， gzip 后差距更小，二进制的大小差不多是 Asm.js 版的 70%。而性能更是完全没有变化，因为其实还是 Asm.js ，只是二进制版而已…… webasm 只是有 parse 效率上的优化……

简单来说， WebAsm 不是非 JS 开发人员的银弹，如果想做前端，还是请使用 JS/TS/CS ，这东西在可见的未来并不会动摇 JS 的地位，只能作为一个高性能计算的解决方案而已。

@wizardforcel 这语气听起来挺让人不爽的，我在很早就说过这相当于 JVM ，只是用这个来说这种方案并没有动摇最原生语言（ java ）的地位而已。

@sagnitude 这确实是一个非常合理的应用场景，解 zip 肯定是可以通过 Asm.js/websam 加速的，不过提到 parse json 的话， asm 方案不会有改变（其实 parse json 本来就是原生 API ），如果你说要把 3D 数据压缩成二进制格式的话，其实即使不用 Asm.js/websam 也是可以做的，现在的浏览器已经广泛支持 TypedArray 标准（这个标准就是做 webGLES 的 khronos 提出的），可以用 JS 来方便地处理二进制数据。简单来说就是现有技术已经可以极大提高你的应用场景的效率了。

@YuJianrong 大 JSON 文件的 parse ，如果调用 js 的话， GC 代价很大，而且无法控制，特别是我预先知道 JSON 文件结构的时候，我可以做针对性的 parse ，然后用 webasm 直接从 C++变量生成 js 对象
二进制文件我现在就在用，但是由于业务要求，拿下来我需要做很多位操作，带来了一定的 GC 负载
最大的问题是，我调用的 Three.js ，把数据往 Three.js 对象里填充的过程中， three.js 有很多数字操作，带来了很大的负载（运算和 GC 都有）
主要是位操作、数字运算这种事情，用 js 来做，太奢侈了，
对大 JSON 3D 模型来说，如果 Three.js 也做了相关工作，可以通过 webasm 解析网络数据，然后把数据直接传给 three.js ，直接传送到 webgl ，不用 js 处理数字
如果可以实现的话，我甚至期望 webgl 画界面可以和浏览器 layout 接近到可接受的程度

@sagnitude
webasm 主要带来的是代码本身大小和 parse 时间的优化，看起来你的场景需要的是大量位操作和数字运算，但代码不一定非常巨大，如果是这样的话用 asm.js 应该已经能得到可观的优化了。如果不想用 emscripten 来把 C/C++翻译成 asm.js 的话，也可以用其他语言直接转译 asm.js 来做 http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-Available-

webasm 相比 asm.js 带来的是代码加载和解析的优势，没有这方面的问题的话直接用 asm.js 就好了。

@YuJianrong 你知道之前为什么没人用吗？

因为能预处理成 js 的语言都是类 js 的语言，而类 js 的语言的确没有一个能超过 js 的。而且 js 也在吸收类 js 语言的优势。

但是如果像 java 、 python 这种东西加入前端行列之后会怎么样呢？ js 跑到后端之后混的也相当不错，你怎么就知道 py 跑到前端之后就一定不会好呢？

你说的由于 js 统治前端时间太长，一时半会不会改变我倒是同意。过个几年再看看吧。


p.s. 虽然这语气听起来挺让人不爽的，但我还是要纠正， asm.js 仍旧是高级语言，不是 bytecode 。只要不是 bytecode ，就会有编译上的种种问题。

@wizardforcel 真是胡说八道。

没有看过我重复了数次了么？ webasm 只是 asm.js 的二进制形式，照你这样说我把机器码反汇编成汇编代码，这样你也能说汇编是高级语言吗？所以汇编“不是 bytecode ，就会有编译上的种种问题”，什么问题？

另外你所幻想的 java 加入前端行列，不需要 webasm(其实 webasm 也没用，毕竟 java 不是 native language)，在 2006 年 Google 推出 Google Web Toolkit 的时候就已经成现实了，发展情况有目共睹。

再重复一下： webasm 脱胎于 asm.js ，是一个用于前端密集计算的解决方案，设计目标并不是取代 JS ，在可预见的未来也不会取代 JS 。

也是醉了，一帮人在喊 js 药丸，拜托，我不管你 geek 也好，语言爱好者也好，你要折腾自己一边折腾去，没人管你，商业的事情根本不鸟你好么， js 再多的缺点大家也习惯了，生态异常强大，再说 js 有缺点其他的就没缺点了？天天喊取代这个取代那个，说取代 PHP 的你看取代了没，去拉勾网上搜搜，二三线城市不说，一线城市后端语言里面依然 PHP 最多，语言本身从来就不是不能克服的东西， js ， php ， java 这三门语言依然持续火热下去