JavaScript 的 WebAssembly 正逐渐走向主流

[Cbdy]

本周发布的 Firefox 52 加入了对 WebAssembly 的支持

JavaScript 精粹提到：大多数编程语言都有精华和糟粕， JavaScript 中的糟粕的比重超出了预料。

虽然很多人不大愿意写 JavaSript ，但是 JavaScript 作为 Web 的'标准语'又无法避开。于是几乎所有主流的通用语言都可以编译成 JavaScript ， Babel 也成为非常流行的编译器

面对 Web 开发中的混乱，程序员们想出了很多方法，比如

• jQuery.js 、 Backbone.js 、 Require.js ：添加一个小的 runtime ，增强 JavaScript 与其宿主
• gulp.js 、 webpack 、 JSLint 等：完善前端开发工具链
• TypeScript 、 ECMAScript 、 CoffeeScript 等、：更好的 JavaScript
• asm.js 、 WebAssembly ：制定 Web 中间码，让 JavaScript 成为一种可选的技术

不用写 JavaScript ，你们高兴吗？

[int64ago]

简单说，如果应用中一些关键点有性能问题，或者其它语言有更好的实现，那么 WASM 显然就很合适做这个事了，但是你好好的一个 Web 应用，大多数时候是用不到这个的，反而一样新出的的 Service Worker 就更接近普通人了

[ChefIsAwesome]

@rashawn 这东西是 web 端啊。因为浏览器上只能跑 js ，所以这东西出来才那么多人觉得有意思。再接着你说的问题，服务器上不止 node 一个选择，为啥那么多人选 node 呢？
说到底，语言跑得快或慢，真的那么重要吗？绝大多数场景下的性能瓶颈都不在语言那吧。

[hronro]

[TypeScript 、 ECMAScript 、 CoffeeScript 等、：更好的 JavaScript]
你知道 ECMAScript 是什么吗？

[droiz]

个人认为还早。

WebAssembly 虽然现在已经完成第一阶段开发，但如果编译到 js ，体积膨胀太大，一个简单的 int add(int ,int); 开 O3 都能达到 400kb 左右，别提更复杂的 c/c++代码，当然随着源码体积的增大，编译产生的副产物大小影响会减小，但体积确实是编译到 js 的一个大问题。如果编译到 wasm ，目前只支持 int,float 等四种简单的数据类型，指针等目前还都不支持，可用性大大受限，但是它解决了编译尺寸问题。

所以目前 WebAssembly 具有可用性的地方只有游戏，视频这些对文件尺寸不敏感，性能要求高的场景，想要全方位替代 js 还早。

[rashawn]

@ChefIsAwesome 我只是根据你假设的那句话来的啊 如果硬件不变的前提下 js 快了 10 倍 说明已经变的跟 c 很像了啊

[murmur]

@droiz 游戏有 unity ，有 cocos ，有 cryengine ，有 unreal ，各家都是先出产品再给钱的策略
不知道 h5 以及相关技术有什么竞争力 你说的是微信里的小游戏么。。

我玩的最好玩的 h5 游戏是钦定的小鸟

[murmur]

@int64ago 浏览器就老实做浏览器的事， java 和 c++的性能和场景都讨论了这么多年了，想要性能 c++、汇编走起

总有一些前端想妄想一统江山，用 c++写 web 的又不是没有， hadoop java 的也有公司用 c++重构， js 以及 js 衍生物咋就那么香呢

[Cbdy]

@hronro 我知道 es 是什么，我这里把 es 与 js 分开说主要是为了区分标准与实现
es 也作出过一些努力，比如'use strict'。但是标准仅仅是标准，只是一个建议， js 的实现掌控在大厂手里

[hronro]

@Cbdy #28 但你这么说，很容易让人产生误解。
`JavaScript 中的糟粕的比重超出了预料`，这其中的糟粕，其实都是 ECMAScript 标准定义而产生的，所以把 ECMAScript 放到`better JavaScript`中去未免有些牵强

[Cbdy]

@hronro '都是 ECMAScript 标准定义而产生的'，这句话不对

[droiz]

@murmur 我指的是网页上的游戏

[hst001]

@SourceMan 不要拿小程序跟这个比，完全两个不一样的东西

[SourceMan]

@hst001 #32 哟，急了~

[pathen]

首先受益的应该是 webgl