DEV Community

Cover image for Javascript is not single threaded! 🀯 🀩
Gautam Vaja for CodeParrot

Posted on • Originally published at

Javascript is not single threaded! 🀯 🀩

Learn about the power of worker threads in JavaScript and how they can enhance your application's performance.

What if I say you that JavaScript is not strictly single-threaded and that there's a way to harness the power of multithreading through worker threads? Intrigued? Let's dive deeper into this topic.

The Myth of Single-Threaded JavaScript 🧐

JavaScript has long been perceived as a single-threaded environment, primarily because of its single-threaded event loop that handles asynchronous tasks, UI rendering, and user interactions in a sequential manner. This design choice helps simplify the development process but can lead to performance bottlenecks when executing long-running tasks.

Enter Worker Threads πŸš€

Worker threads are JavaScript's answer to achieving parallelism, allowing you to run scripts in background threads and perform heavy tasks without interrupting the main thread. This means you can execute computationally expensive operations, such as data processing or complex calculations, without compromising the responsiveness of your web application. They allow you to execute JavaScript in parallel, offering a solution for offloading processing tasks from the main event loop, thus preventing it from getting blocked.


Key Features and Benefits:

  • Parallel Execution: Worker threads run in parallel with the main thread, allowing CPU-bound tasks to be handled more efficiently.
  • Non-Blocking: By delegating heavy lifting to worker threads, the main thread remains unblocked, ensuring smooth performance for I/O operations.
  • Shared Memory: Worker threads can share memory using SharedArrayBuffer, facilitating efficient communication and data handling between threads.

How Worker Threads Operate πŸ› οΈ

Worker threads, stabilized in Node.js version 12, offer an API for managing CPU-intensive tasks effectively. Unlike clusters or child processes, worker threads can share memory, allowing for efficient data transfer between threads. Each worker operates alongside the main thread, equipped with its event loop, enhancing the application's capability to handle multiple tasks concurrently.

A Simple Example

Consider a Node.js application where the main thread is tasked with a CPU-intensive operation, such as image resizing for different use cases within an app. Traditionally, this operation would block the main thread, affecting the application's ability to handle other requests. By offloading this task to a worker thread, the main thread remains free to process incoming requests, significantly improving the application's performance and responsiveness.

Code Snippet for Image Resizing Using Worker Threads
// main.js
const { Worker } = require("worker_threads");

function resizeImage(imagePath, sizes, outputPath) {
  const worker = new Worker("./worker.js", {
    workerData: { imagePath, sizes, outputPath },

  worker.on("message", (message) => console.log(message));
  worker.on("error", (error) => console.error(error));
  worker.on("exit", (code) => {
    if (code !== 0)
      console.error(new Error(`Worker stopped with exit code ${code}`));
Enter fullscreen mode Exit fullscreen mode
// worker.js
const { parentPort, workerData } = require("worker_threads");
const sharp = require("sharp"); // Assuming sharp is used for image processing

async function processImages() {
  const { imagePath, sizes, outputPath } = workerData;
  try {
    for (const size of sizes) {
      const output = `${outputPath}/resize-${size}-${}.jpg`;
      await sharp(imagePath).resize(size.width, size.height).toFile(output);
      parentPort.postMessage(`Image resized to ${size.width}x${size.height}`);
  } catch (error) {
    parentPort.postMessage(`Error resizing image: ${error}`);

Enter fullscreen mode Exit fullscreen mode

In this example, the main thread initiates a worker thread for resizing an image, passing the necessary data through workerData. The worker thread performs the resizing operation using the sharp library and communicates the progress back to the main thread without blocking it.

Real-World Applications of Worker Threads 🌐

Worker threads are not a panacea for all performance issues but are particularly effective in scenarios involving CPU-intensive operations such as:

  • Complex calculations or algorithms
  • Image or video processing
  • Data sorting or manipulation on large datasets

Best Practices and Considerations πŸ“

  • Security: Keep in mind that workers have some limitations for security reasons, such as no access to the DOM.
  • Performance: While workers are powerful, spawning too many workers can lead to memory and performance issues. Always test and optimize.


Worker threads offer a powerful mechanism for enhancing JavaScript's processing capabilities, breaking the myth of its single-threaded limitation. By judiciously leveraging worker threads, developers can significantly improve the performance and responsiveness of their applications. As JavaScript continues to evolve, exploring its concurrent capabilities will undoubtedly uncover new patterns and practices for building efficient, scalable web applications.

Top comments (2)

joelbonetr profile image
JoelBonetR πŸ₯‡ • Edited

I think you're mixing concepts here, it's a complex topic so no finger pointing, I've been there as well πŸ˜‚

  • Web Workers run in client side and are often used to handle PWA background processes such running cache-first strategies among others. These are the ones that can't access the DOM for security reasons despite running in the client side.

  • Worker threads run in Node runtime environment (server side) and are used to parallelize tasks such the ones you described in real world applications. These of course can't access the DOM but the reason is that it's a client API so it's not available in Node

You might be interested in Child Processes and clusters as well.

Last but not least, some concepts to take into account:

  • JavaScript is a language, it doesn't define a threading model and it's not necessarily single threaded.
  • The JS event loop implementation has historically been single threaded (its asynchronous nature makes it hard to get any benefit from multi-threading-it).
  • Most browsers have historically been single threaded (that might be the origin of the "myth"?), nowadays all of them are probably multi-threaded (chrome, chromium-based such Arc browser, Edge and so on are multi-threaded for sure).
  • Web Workers is not part of JavaScript, it is a browser feature which can be accessed through JavaScript.
  • Worker threads, child processes and clusters (among others) are not part of JavaScript, they are Node features which can be accessed through JavaScript.

important considerations

Aforementioned multi-threading features need to be picked with a grain of salt.
Was about to explain stuff but found this guy explaining it better than I could so here's the link instead

Best regards

gajananbodhankar profile image
Gajanan Bodhankar

Very useful info, I read it and it helped me in an Interview. Thanks though!!