The quick and simple answer is: to have it excel in the only area where Node has suffered in the past: dealing with heavy CPU intensive computations. This is mainly why Node.js is not strong in areas such as AI, Machine Learning, Data Science and similar. There are a lot of efforts in progress to solve that, but we’re still not as performant as when deploying microservices for instance.
So I’m going to try and simplify the technical documentation provided by the initial PR and the official docs into a more practical and simple set of examples. Hopefully that’ll be enough to get you started.

So how do we use the new Threads module?
To start with, you’ll be requiring the module called “worker_threads”.
Note that this will only work if you use the
--experimental-worker
flag when executing the script, otherwise the module will not be found.
Notice how the flag refers to workers and not threads, this is how they’re going to be referenced throughout the documentation: worker threads or simply workers.
If you’ve used multi-processing in the past, you’ll see a lot of similarities with this approach, but if you haven’t, don’t worry, I’ll explain as much as I can.
What can you do with them?
Worker threads are meant, like I mentioned before, for CPU intensive tasks, using them for I/O would be a waste of resources, since according to the official documentation, the internal mechanism provided by Node to handle async I/O is much more efficient than using a worker thread for that, so… don’t bother.
Let’s start with a simple example of how you would go about creating a worker and using it.
Example 1:
const { Worker, isMainThread, workerData } = require('worker_threads');
This time around, we’re requesting the homepage for Google.com and at the same time, sorting a randomly generated array of 1 million numbers. This is going to take a few seconds, so it’s perfect for us to show how well this behaves. We’re also going to measure the time it takes for the worker thread to perform the sorting and we’re going to send that value (along with the first sorted value) to the main thread, where we’ll display the results.
![]()
The main takeaway from this example, is the communication between threads.
Workers can receive messages in the main thread through the
on method. The events we can listen to are the ones shown on the code. The message event is triggered whenever we send a message from the actual thread using the parentPort.postMessage method. You could also send a message to the thread’s code using the same method, on your worker instance and catching them using the parentPort object.
In case you’re wondering, the code for the helper module I used is here, although there is nothing note-worthy about it.
Let’s now look at a very similar example, but with a cleaner code, giving you a final idea of how you could structure your worker thread’s code.
Example 3: bringing it all together
As a final example, I’m going to stick to the same functionality, but showing you how you could clean it up a bit and have a more maintainable version.
Breaking this one down, we see:
![]()
That is going to be it for this article, I hope you got enough to understand how to get started to play around with this new module. Remember that:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments
Post a Comment