I'm sure you've heard all the hot stuff with WebAssembly. WebAssembly is so flexible that people start making standalone runtimes from the WASI standard. But let me tell you one thing, Node.js and WebAssembly is not slated to compete with each other, and never will.
If it compiles in LLVM, it can compile to WebAssembly - One of the promising features of WebAssembly is anything that LLVM supports can be compiled to the Stack-based VM of WebAssembly's (in standard) bytecode. You get the benefit of using whatever language you want, and it'll work on the browser. Using OpenGL for this project? Don't worry, because WebGL is based on OpenGL ES 2.0/3.0, and it'll surely run!
More control on the memory - I'm pretty sure since we're dealing with a runtime that gives support to language that has inherent control on memory, it would give you manual memory management, right? Well, you're not wrong, because that's one of its main benefits. So you can optimize your memory usage.
And much much more - WebAssembly is now working on threading and SIMD, things in the runtime side that would WebAssembly much more capable. Can't wait? They're already in your browsers, just enable the feature flag.
Much more importantly, WebAssembly started out from asm.js which had similar aims, but suffered on some performance issues. It was intended to help developers to port existing applications to the web, and sure enough, it was good enough that games started to get ported in it.
With this benefits, you may think Node.js will get superseded? And you may think this two worlds would clash despite sharing the ecosystem? No.
Good question! Node.js has been real finicky with Native Node modules, don't get me started on how many native modules has failed to compile on my environment despite having the adequate tools. And that's an area WebAssembly can help.
This opens for a lot of possibilities, and I think we should adapt this kind of approach.
Okay hear me out, I know WebAssembly is quite in its early days, but WebAssembly has been doing some major strides when it comes to improving its runtime capabilities that we may not even need native node modules at all.
We leave the compilation problems from the package user and instead let them focus on what matters most, building the next hit application.
Instead the compilation is done from the publisher's side. And it reduces the friction for modules that requires such native capabilities, without needing to rely on the package user's environment to compile it for their Node.js runtime.
Of course the most important reason of why WebAssembly exists is opening a future of a much more powerful and feature-rich modern web. Soon, services by services that would otherwise require a serverside equivalent would be moved over to WebAssembly, and it would complement on current trends like Serverless. It's a future we should openly embrace, and a future that sounds too good to be true, but it's just around the corner.
WebAssembly may not be the runtime we asked for but its the one Node.js deserved, and probably the one we desperately needed.