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.

A quick overview

If you give WebAssembly a look in W3C's site it seems very flexible and more powerful than JavaScript would ever be. It presents benefits such as:

• More integer precision - We've been limited to 56-bit integers with JavaScript, and even if we have 64-bit precision, BigInt can't be used with normal arithmetic or math operations compared to contemporaries.

• 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.

Well what about Node.js

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.

In fact, Node.js actually added support to WASI, which made WebAssembly application development possible even in the runtime, but even then, WebAssembly is not even slated to replace JavaScript, but to complement it.

If the two doesn't clash, then how would they help each other?

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.

The main applications of using Native Node Modules is basically for modules that requires more precision, say like bcrypt, or WebP image conversion. You think they'll need something like C++ to work? Then you're not wrong, but instead of targeting native modules, why not try targeting WASI? Sounds impractical you may say, but the future isn't so far off, because someone did it already and its amazing. We leave the work that requires more precision to WebAssembly, and the JavaScript side would just output it - and you won't need to compile the module, because its done at the publishing side.

This opens for a lot of possibilities, and I think we should adapt this kind of approach.

WebAssembly on the NPM ecosystem - a world without Native Node Modules

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.

Maybe I'm day-dreaming but the future is so bright for such a complementary runtime for JavaScript that I kept wondering - When's WebAssembly 2.0 coming out!?

Raison D'etere

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.