Introduction

The right concurrency tool in Node.js depends on the kind of work you need to run. For modern Node, the short answer is simple: use ordinary async I/O for most server work, use worker_threads for CPU-bound JavaScript, and avoid Fibers as a design choice in new code.

Start with the Node Execution Model

Node already handles many concurrent I/O tasks well with its event loop. If your program is mostly waiting on:

• sockets
• databases
• files
• HTTP APIs

then you often do not need extra workers at all. Promises, streams, and async functions are the natural concurrency model.

Extra threads matter mainly when JavaScript itself is doing expensive CPU work such as:

• image processing
• compression
• parsing large documents
• simulation
• heavy data transforms

Fibers Are Not the Modern Answer

Fibers were a way to pause and resume execution so asynchronous code could look synchronous. They were never the same thing as parallel execution, and they do not solve CPU-bound concurrency by themselves.

More importantly, the fibers package is effectively obsolete for modern Node runtimes. Its own npm page recommends avoiding it when possible and notes incompatibility with newer Node releases. That alone makes it a poor choice for a current system.

So even before performance tradeoffs, Fibers lose on maintainability and runtime compatibility.

What "Web Workers" Means in Node

Browser Web Workers and Node worker threads are conceptually similar: both move work off the main execution context and communicate by message passing. In Node, the real API you should use is node:worker_threads.

That matters because "Web Workers" is not the normal Node.js term for production server code. The official Node mechanism is Worker from the worker_threads module.

Node's documentation describes a Worker as an independent JavaScript execution thread. That is the feature intended for CPU-bound concurrent JavaScript inside one process.

A Minimal Worker Thread Example

1const { Worker, isMainThread, parentPort, workerData } = require("node:worker_threads");
2
3if (isMainThread) {
4  const worker = new Worker(__filename, { workerData: 10_000_000 });
5
6  worker.on("message", (result) => {
7    console.log("result:", result);
8  });
9
10  worker.on("error", (err) => {
11    console.error(err);
12  });
13} else {
14  let total = 0;
15  for (let i = 0; i < workerData; i += 1) {
16    total += i;
17  }
18  parentPort.postMessage(total);
19}

This is real parallel execution of JavaScript work. The main thread stays responsive while the worker computes.

When Threads Are Better

Use worker threads when:

• the task is CPU-heavy
• you want to keep one Node process
• you can pass messages or transferable data between workers

This is the modern default answer for "how do I run concurrent compute tasks in Node."

There is one important caveat from the Node docs: creating a new worker for every tiny task is expensive. For repeated workloads, use a worker pool instead of spawning one thread per request.

What About Processes

The question mentions threads, but in Node there is another common option: separate processes using child_process or clustering patterns. Processes are heavier, but they provide stronger isolation and separate memory spaces.

That means the rough decision tree is:

• async I/O for normal network and file concurrency
• 'worker_threads for CPU-bound JavaScript within one process'
• separate processes when isolation matters more than shared-memory convenience

Practical Recommendation

For modern Node.js:

• do not choose Fibers for new work
• do not reach for worker threads if the job is already I/O-bound
• do choose worker_threads when JavaScript computation is the bottleneck

If you are building a web server, most request concurrency should still stay on the event loop. Only offload the expensive compute sections.

Common Pitfalls

The most common mistake is using threads to solve an I/O problem that async code already handles well. That adds complexity without improving throughput.

Another mistake is treating worker threads as free. Message passing and worker startup have cost, so tiny jobs may get slower, not faster.

People also sometimes assume Fibers provide parallelism. They do not. They change control flow style, but they do not create multiple CPU-executing JavaScript threads.

Finally, do not overlook Node's existing runtime behavior. Some built-in operations already use libuv's background thread pool under the hood, so not every blocking-looking task needs manual worker management.

Summary

• For modern Node.js, worker_threads is the right built-in tool for CPU-bound concurrent JavaScript.
• Fibers are obsolete and not a good choice for new code.
• Browser-style "Web Workers" maps to Node's worker_threads concept, but the Node API name is different.
• Most I/O concurrency in Node should stay on the normal async event-loop model.
• Use worker pools, not one-off workers per tiny task, when the workload is frequent.