Multi-threaded javascript? Trying the new napa.js from Microsoft

And this is not about Web Workers.

Today Microsoft released on their Github a new node module called Napa.js. The promise of this framework is to implement a Multi-threaded JavaScript runtime on v8 environments.

So, the day of multi-threaded javascript has really come? Is today the day that someone will have to update 2008 Stackoverflow questions? Not so fast.

The framework was designed to work at the server side of the stack, and not at your browser. This means that these guys at Stackoverflow will have to wait a little more or keep making workarounds for such features.

(source: napa.js github)

The package was build to bring performance for code that have a hunger for processing power, as put on the FAQ at their github:

In short, Napa.js provides a multi-threaded JavaScript programming model that enables developers to write computation heavy code in JavaScript, without blocking Node event loop.

And they also mention that:

You should use it when: 1) CPU bound logic that may block Node event loop 2)Complex workflow that may involve parallel execution of JavaScript code

Giving it a quick test

So, let's give it a shot to see how this works.

To build an example and Proof-of-Concept, I came up with a fake code that implements a "CPU bound logic that may block Node event loop". In this scenario, you guessed it, an "while(true)".

Before we start, you can check the whole picture of the following files and tests at my github here.

Creating the non-threaded code

For our fake complex code we will get an array of numbers, multiply them by a factor and then run a while(true) for a certain amount of time to simulate high CPU processing and blocking node event loop.

The end file looks like this:

Creating the threaded code

Starting with the standard code, I ported it to a threaded scenario following the guidelines and examples on napa.js github.

Little explanation: Same logic but this time spliting the longSequence of numbers in smaller batchs to fill the numbers of threads configured on; and then processing them in a distributed way. At the end of all the processing, fetching the results from all the threads and console.log them.

The end file looks like this:


Okey, so after running the two files, here is what I got.

Running non-threaded file:

Total runtime of 1104ms, for processing 100 numbers with 10ms of blocking node event loop between them. Everything as expected, this is the common behavior.

Running threaded file:

It worked! Running the same code under 4 threads gave me the same result in 4x less time.


It worked pretty nicely and I'm very excited for having these kind of features with this ease in Node.js. Should you use it on every project and thread all your processes? Definitely not.

But if you are in the mentioned scenarios of use for this framework, go for it, he will give you a huge boost on performance. But if you are not, the benefits tend not be as good if you put in consideration the effort of implementation and added complexity.

In the end of the day, it's a nice framework and have a lot more cool features that I barely touch here, so make sure to check them out and know a little more about all the power that this can brings to the Javascript ecosystem and perhaps your project, who knows.

Like what you read? Give Gabriel Age a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.