大家在争论 deno 的时候提到 ts 和 web assembly，突然想到那岂不是也可以 server assembly 一下？

[rrfeng]

然后 js 编译成二进制的后端可执行程序跑在一个又从浏览器扒出来的 vm 上

历史的车轮总是在绕圈子…

[rrfeng]

粗浅了，原来本身就有 non-web 的设计

https://webassembly.org/docs/non-web/

[polythene]

后端的语言已经够多了，求求你不要再搞轮子了，学不动了。。。

[nfroot]

我一直以为 V2EX 最近频繁出现的 deno 是打错字了……囧。

[AV1]

请问编译成 web assembly 跑在服务器上相比直接编译成 native code 有何优势？

[reus]

vm 本来就是跑 bytecode，bytecode 就是编译出来的。

[aaronly]

服务器 wasm 并看不到有什么优点，追求效率和通用性为什么不直接上 c/c++/rust/go，干嘛要在运行时再套一层 vm 亦或是用 wasm 的方式编译成机器码

> Non-Web environments may include JavaScript VMs (e.g. node.js), however WebAssembly is also being designed to be capable of being executed without a JavaScript VM present.

[zeromake]

@aaronly 应该是考虑到日后会有各种语言写的库，可以通过 wasm 无损使用，还是看生态。

[rrfeng]

@aaronly

不然，node 为什么火其实很大原因是前后 js 统一。各种库可以通用。
go c java 也做不到这一点。但是 wsam 可以通过各种语言生成，相当于把 go c java 搬到前端去了。出现一统方案是必然的，至于好不好用和发展前景就再看了

[noli]

我已经在狠很多个地方布道过了，那就是很多语言可以编译出 webassembly，
所以 js 可以安息了。
论语言设计的优势，js 真的没有多少优势，无论是前端还是后端的应用场景。
唯一的优势就是在浏览器中的先发优势。

[janxin]

为什么不直接 node ？除了麻烦以外没什么收益

[aaronly]

@rrfeng 那就得看应用场景了，高并发情况下恐怕没人愿意牺牲 20%性能去采用通用库的方案。但扯到应用场景，本来各个语言都有自己的专长，如果只是为了一统天下而那恐怕不是 wasm 的目标。不如用心做好的 web 的场景， 富交互情景甚至以后的 vr/ar/mr 更需要这个技术。