JavaScript: Web Workers and Multithreading

A fundamental rule of JavaScript is that it is single-threaded. All UI rendering, user interactions, and JavaScript execution happen on a single "Main Thread".

If JavaScript is single-threaded, how can we execute a massive computation (like image processing or parsing a 50MB JSON file) without freezing the browser?

The answer is Web Workers.

1. What are Web Workers?

Web Workers provide a standard way for browsers to run JavaScript in the background, on an entirely separate CPU thread, completely independent of the Main Thread.

Because they run in a separate thread, heavy calculations will not block the UI. The user can continue scrolling, clicking, and interacting with the page seamlessly.

The Strict Limitations of Web Workers

Because Workers operate in a parallel universe, they have severe restrictions to prevent race conditions:

1. No DOM Access: Workers cannot read or manipulate the HTML DOM. (document.getElementById will throw an error).
2. No Window Object: They do not have access to the global window object or its associated properties.
3. Communication only via Messages: The Main Thread and the Worker Thread can only communicate by passing messages (strings or serializable data) back and forth. They do not share memory.

2. How Web Workers Communicate (Message Passing)

Communication between the Main Thread and the Worker relies on the postMessage() method and the onmessage event listener.

Step 1: Create the Worker Script (worker.js)

This is the file that will execute in the background thread.

// worker.js
self.onmessage = function(event) {
  const data = event.data;
  console.log("Worker received data:", data);
  
  // Perform heavy computation...
  let result = 0;
  for (let i = 0; i < 1_000_000_000; i++) {
    result += i;
  }
  
  // Send the result back to the main thread
  self.postMessage(`Computation complete! Result: ${result}`);
};

Step 2: Initialize the Worker in the Main Thread (main.js)

// main.js
 
// 1. Initialize the Worker pointing to the script file
const myWorker = new Worker('worker.js');
 
// 2. Listen for messages coming BACK from the worker
myWorker.onmessage = function(event) {
  console.log("Main thread received:", event.data);
  // Safely update the DOM with the result here!
  document.getElementById('result').innerText = event.data;
};
 
// 3. Send data TO the worker to start the computation
console.log("Sending task to worker...");
myWorker.postMessage("Start the heavy math!");

Terminating a Worker

Workers consume system resources. When a worker is no longer needed, you must manually kill it to free up memory.

myWorker.terminate();

3. SharedArrayBuffer (Advanced)

Historically, calling postMessage() cloned the data being sent (using the structured clone algorithm). If you sent a 100MB file to a worker, it copied 100MB in memory, which was slow.

Modern JavaScript supports SharedArrayBuffer, which allows the Main Thread and the Worker to share the exact same block of memory. This enables incredibly fast, true concurrent programming, but requires careful usage of the Atomics API to prevent race conditions (two threads mutating the data at the exact same microsecond).

Senior-Level Interview Answer

JavaScript is fundamentally single-threaded, meaning long-running synchronous tasks will block the Event Loop and freeze the browser's rendering pipeline. Web Workers solve this by providing an API to spawn background OS threads that execute JavaScript independently of the main UI thread. Because they run in an isolated execution context, Web Workers do not have access to the DOM or the window object. Communication between the main thread and the worker is handled asynchronously via the postMessage API and message events, which typically serialize and clone data. For high-performance use cases like game engines or video processing, data can be transferred by reference using Transferable Objects, or memory can be strictly shared using SharedArrayBuffer and Atomics to prevent race conditions.

Common Interview Mistakes

❌ Confusing Web Workers with Service Workers

Interviewers often ask to compare them.

• Web Workers: Used strictly for parallel computing and offloading heavy math from the main thread.
• Service Workers: Used as a network proxy to intercept HTTP requests, cache assets, and enable offline functionality (PWA).

❌ Thinking Promises/Async/Await prevents UI blocking

A common mistake is claiming that wrapping a heavy for-loop inside a Promise makes it non-blocking. It does not. Asynchronous JavaScript (Promises, setTimeout) merely delays when the code runs. When the heavy loop finally executes, it still executes on the main thread, freezing the UI. Only Web Workers provide true parallel execution.