Wait... what? Worker threads in Node.js have dropped their “experimental” flag?

Meaning that you no longer need to:

• accept the fact that Node.js is a single-threaded JavaScript runtime using asynchronous code, one that restricts you to working in a concurrent way (and thus... the “callback hell”)? 
• restrain yourself from using it in resource-intensive projects, knowing that Node.js can't handle CPU-intensive operations?

Now, let us savor this news (a no longer “steamy fresh” one, since Node v11.7.0, along with this update for the worker threads, was released on the 18th of January) and dig into the... juicy details:

 

1. Worker Threads in Node.js: The Most Craved for Feature

And we've been longing for Node.js multithreading for so long...

The first sign that something good was on its way was the release of the worker_threads module along with Node.js v10.5.0.

One still “waving” its experimental flag back then...

But why were worker threads such a needed feature in Node.js? Why do they matter so much?

What old pain point are they expected to address?

Concurrency.

Or “callback hell” if you prefer. The most frustrating limitation that any Node.js developer is faced with. 

And it becomes even more frustrating if we think that otherwise Node.js's famed for its execution speed.

That, of course, if we're talking about I/O-bound apps. For its reputation fades when it comes to... resource-heavy app projects, with a high load on the processors.

It just doesn't have the capabilities to consume all the machine resources available.

Now, here's this old Node.js limitation summed up in a few words:

Being a single-threaded system, Node.js's remarkably good at handling various I/O calls. Yet, since it uses threads in a concurrent way (using promises and callbacks) it's bad at performing CPU-intensive operations.

Operations that call for parallel processing instead.

For worker threads...

 

2. Free from the Old Restrictions on CPU-Intensive Tasks

With thread workers in Node.js, enabled now by default, you can break free from the old restrictions regarding CPU-intensive tasks.

Basically, now you get to set up multiple threads to free the main thread from some of its work and empower it to process requests in parallel.

And, implicitly, a lot faster. 

So, step into a new era where you can run CPU-heavy tasks. That kind of operations where... millions of elements need to be sorted at high speed.

Note: in relation to the worker threads in Node.js, starting with its 11.8 version we've got process.unmask() available as a read-only function, as well as an execArgv option.

Meaning that we get command-line options support from now on.

 

3. Final Word of... Caution

My advice for you is:

Handle worker threads in Node.js with... care.

I know you're tempted to just squeeze them in to fit any type of optimization scenario:

• speeding up the bundling
• speeding up the HTML parser

Yet, do keep in mind that they're still quite heavy. And so, they do call for... cautious handling.   

Moderate your enthusiasm.

And resist the “temptation” of turning these long-awaited worker threads into some... “fits all CPU-heavy tasks” type of tools. 

---