WebAssembly 的介绍

[livecoding]

WebAssembly 是最下一代的浏览器语言。终于将写在浏览器上的汇编语言变成了现实了。大家可以了解一下相关的工作。 同时也欢迎大家踊跃注册账号。

观看视频

[sagnitude]

@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 ，解析时间也能大大缩小
不仅传输的数据变少了，渲染时间还变少了，简直没有理由不支持

[YuJianrong]

@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 的地位，只能作为一个高性能计算的解决方案而已。

[YuJianrong]

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

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

[sagnitude]

@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 接近到可接受的程度

[YuJianrong]

@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 就好了。

[wizardforcel]

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

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

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

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


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

[YuJianrong]

@wizardforcel 真是胡说八道。

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

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

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

[Wangxf]

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