WebAssembly and Node.js - No, they won't compete with each other, they'll coexist
Tags: webassembly, node, javascript
Published: 2020-05-06 12:06:41

---
title: WebAssembly and Node.js - No, they won't compete with each other, they'll coexist
published: true
description: WebAssembly has been there for a quite a while now, and it seems to compete with Node.js, but that's not really the case.
tags: webassembly, nodejs, javascript
cover_image: https://images.unsplash.com/photo-1484417894907-623942c8ee29?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=2089&q=80
---

I'm sure you've heard all the hot stuff with WebAssembly. WebAssembly is so flexible that people start making [standalone runtimes](https://wasmer.io) 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](https://webassembly.org) 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](http://asmjs.org/) 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](https://linuxgameconsortium.com/free-and-open-source-3d-game-cube-2-sauerbraten-ported-t/).

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](https://nodejs.org/api/wasi.html), 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](https://www.npmjs.com/package/@saschazar/wasm-webp) 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.