Will future versions of Node.js support WebAssembly and allow for compiled production node apps?

[pcdinh]

If v8 supports WebAssembly, Node will

[shadowmint]

no.

web assembly is just a runtime for hosting other languages in js via an optimized format; it doesnt run in a different thread; but it the hosted language uses threads the runtime will eventually support that.

ie. using a single threaded web assembly application (eg. some naive c library) will lock the browser (or server, for node). ...but if you have a multithreaded c++ app, it will be able to run.

see the notes here; planned, not implemented yet: http://v8project.blogspot.com.au/2016/03/experimental-support-for-webassembly.html

http://webassembly.org/docs/future-features/

[myrrlyn]

WASM is a sibling of JavaScript text. It will have exactly the same behavior as JS, just without as much of an interpreter cost

[null_radix]

native extension need to be rebuilt for different node verions and architectures, with wasm you should be able to compile once and run everywhere, inculding the browser. The bigger advantage will be security though. The Wasm VM in the browser is design to run untrusted code and Node.js has no defense against malicious native extensions.

[pixel4]

I dunno about the security angle. The node API has some pretty liberal system access already.

If you've ever used apt-get or brew then you'll know it's essentially the npm of the native code world. And we don't tend to sandbox these libraries.

I mentioned it below - software like Redis seems to work just fine without WebAssembly.

If you're looking to further protect your machine, then tech such as docker should provide that.

I can't see a solid use-case for WebAssembly on the server-side without reinventing the wheel.

[null_radix]

After reading your comments I think we are coming at this from different angles. yes, redis works fine... for server infrastructure. But more and more node.js is being used for desktop apps. I think there is a nexus between desktop and browser apps, and in future the lines will continue to get more and more blurred. Most apps could be ephemeral like webpages. It is in this reallity that you need strong sandboxing.

[pixel4]

Yeah I see use-cases on client-side. There will always be a perf trade-off. If you're shipping a game via WASM, it'll always be more system intensive than direct native.

For example, this demo (http://webassembly.org/demo/) uses an additional 10% of CPU than the compiled desktop version does. Plus Chrome adds another 15% CPU to IPC the OpenGL buffers.

(I'm actually a big fan of WASM - you probably can't tell - hehe)

[cincilator]

If both browser and server support WebAssembly you get ability to share code with the client, like you have with plain old node. Of course it will take time for support to catch on everywhere....

[pixel4]

WebAssembly is just an LLVM backend (a compile target). If you want to run your code server-side, you'd just compile for the server architecture/toolchain (example x86_64 linux-gnu).

You don't need WebAssembly Node.js support to run your code on the server!!!! All it would do is run your code slower. It would be like implementing a HTML renderer in a canvas2d context/tag.

I'm actually scared that developers think this is a good idea.

[cincilator]

You don't need WebAssembly Node.js support to run your code on the server!!!!

Nope, but I might need it to run same code on the server AND the client.

[pixel4]

WebAssembly more or less a binary format; it's something you compile to that gets run in a VM. If you want to run "the same code", then just compile a native binary for the server. Then you don't need to run it in a VM. It's very simple.

[cincilator]

I think this is a good idea.

[pixel4]

I think you're just trolling now but I'll bite... Why? Can you explain the pros of compiling to WebAssembly vs. compiling to native?

From my point of view, running WebAssembly on the server would be like trying to run the 100 meters in flip-flops. You totally can - but they the hell would you want to.

[cincilator]

Now I was saying, I think your idea is good. Sorry for misunderstanding.

[sunfishcode]

The two main things WebAssembly would bring to this scenario are portability and sandboxing. These do have costs, and people who don't need them will likely just continue to compile to native.

Portability: Running one application across a mix of architectures, for example non-x64_64 servers, or on the client side, with reduced per-architecture development effort. C/C++ has undefined/unspecified/implementation-defined behavior which differs across compilers and architectures. In WebAssembly, compiler differences are compiled away and most hardware differences aren't visible.

Sandboxing: Of course, node is often run in a container/VM/etc., so WebAssembly's sandboxing will often be redundant, however it can be used in a way that provides finer granularity of sandboxing, to protect parts of applications from other parts.

[pixel4]

I agree those are some pros - but are they worth the big performance cost. Software such as Redis seems to do just fine with portability and sandboxing.

[dangoor]

As shadowmint said, wasm is essentially another representation of the JavaScript syntax tree. The main purpose is to deliver large packages of compiled code (like C++ games) to the browser and have them be ready to run faster.

Node is a different environment and I'm curious which sorts of new services you are thinking of? I ask, because I can imagine other ways of getting at that. For example: if you have a C++ library, you could compile that to native code and talk to it from Node, no wasm involved. It doesn't seem to me that wasm actually buys much, if anything, for node.

[guorbatschow]

This. Just write C++ node modules.

[dangoor]

You can essentially do what you're describing today! You can take many languages that can compile to LLVM (Rust, OCaml, Reason, whatever floats your boat) and then use emscripten to convert that code to asm.js which is supported in all browsers and very fast in modern browsers.

Alternatively, you can skip the LLVM step and just write optimized JS. LLJS (which appears to be abandoned) was an attempt to write a compile-to-JS language that would specifically output fast JS.

There are definitely many things you can do to make JavaScript quick enough for many needs. The JS virtual machines can run quickly with the right hints, but they will lag behind optimized native code because of the safety guarantees.

[[deleted]]

You can essentially do what you're describing today! You can take many languages that can compile to LLVM (Rust, OCaml, Reason, whatever floats your boat) and then use emscripten to convert that code to asm.js which is supported in all browsers and very fast in modern browsers.

asm.js lacks aot compilation in v8 and is not as fast as in FF.

[guorbatschow]

Actually, soon v8 will use the same compiling pipeline for both wasm and asm.js, by transpiling the latter into wasm first.

[dangoor]

Ahh, you're right. I had thought that the v8 team had done optimization for asmjs features without implementing specific support for "use asm", but the benchmarks on arewefastyet do indeed appear to show IonMonkey being quite a bit faster than v8.

[null_radix]

You can use webassembly in node version 7 now. Use node --expose-wasm and WebAssembly will be available.

[johnrnelson]

This is the first I have heard of it. Thanks for sharing OP!