That certainly could be a theoretical future for Asm.js! In my post I link to a pure-JavaScript port of SQLite that runs in Node.js (using Emscripten): https://github.com/kripken/sql.js

Presumably either Node would have to switch to Mozilla's Spidermonkey or V8 would have to implement full performance support for Asm.js.

Hopefully the V8 guys have more respect for asm.js than they do E4X, which would be really nice to have in NodeJS. Even though V8 is from Google devs and not directly associated with NodeJS, I think they should be at least considerate of features that are useful outside the browser, but need integration into the engine itself.

But if you're cross-compiling from C++ to get asm.js, what would be the advantage? The upside is easier distribution of code, but presumably in the case of node that wouldn't be a big upside.

Considering compilation differences between 32/64 bit versions across Linux, Windows and OSX, let alone different versions of NodeJS most native modules require a build system on the platform... As someone who's stuck with windows deployments for NodeJS work, it's been a little painful... I'd take the little performance hit for modules that load/run transparently.

I think, that having code in C/C++ is much better than in obscure dialect of JavaScript.

Most of Node's core is already written in Javascript. Also, I can't see what would be the benefit of using Asm.js vs calling C/C++ libraries directly using FFI.

V8 doesn't support Asm.js.

... in an optimized fashion. Being valid JS, V8 could run Asm.js code.

Which doesn't matter in this case, as this fact doesn't give any incentive to Node folks to use it in V8.

Not yet, but if Chrome takes the route of optimizing the asm.js subset of javascript, node.js could gain a lot of traction as a generic high performance asynchronous platform.

And that may just be worth getting excited for.

NodeJS is already gaining traction as a high performance asynchronous platform... Though it's best fit has been in situations that are more IO bound than CPU bound, where it's been a bad fit. This could make it a better fit for CPU tasks, with high IO.

Right now, I have a few workers managed in node, that run compiled code. It works pretty well, but having more of that as modules directly available in Node, with nearly the same performance would be really compelling.

Not needing to compile certain NodeJS modules is what I'd find really compelling.

...not yet, anyway.