Nodejs中,大家在争论deno时提到的ts和web assembly,让人联想到是否也能进行server assembly一下?
Nodejs中,大家在争论deno时提到的ts和web assembly,让人联想到是否也能进行server assembly一下?
然后 js 编译成二进制的后端可执行程序跑在一个又从浏览器扒出来的 vm 上
历史的车轮总是在绕圈子…
粗浅了,原来本身就有 non-web 的设计
https://webassembly.org/docs/non-web/
后端的语言已经够多了,求求你不要再搞轮子了,学不动了。。。
我一直以为 V2EX 最近频繁出现的 deno 是打错字了……囧。
请问编译成 web assembly 跑在服务器上相比直接编译成 native code 有何优势?
vm 本来就是跑 bytecode,bytecode 就是编译出来的。
服务器 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.
应该是考虑到日后会有各种语言写的库,可以通过 wasm 无损使用,还是看生态。
不然,node 为什么火其实很大原因是前后 js 统一。各种库可以通用。
go c java 也做不到这一点。但是 wsam 可以通过各种语言生成,相当于把 go c java 搬到前端去了。出现一统方案是必然的,至于好不好用和发展前景就再看了
我已经在狠很多个地方布道过了,那就是很多语言可以编译出 webassembly,
所以 js 可以安息了。
论语言设计的优势,js 真的没有多少优势,无论是前端还是后端的应用场景。
唯一的优势就是在浏览器中的先发优势。
为什么不直接 node ?除了麻烦以外没什么收益
那就得看应用场景了,高并发情况下恐怕没人愿意牺牲 20%性能去采用通用库的方案。但扯到应用场景,本来各个语言都有自己的专长,如果只是为了一统天下而那恐怕不是 wasm 的目标。不如用心做好的 web 的场景, 富交互情景甚至以后的 vr/ar/mr 更需要这个技术。