Web Workers Fundamentals

The plain-language idea

JavaScript running in your page has exactly one main thread, and that same thread also handles layout, painting, and responding to clicks and scrolls. Run something expensive on it — sorting a huge array, parsing a big file, hashing something — and the whole page freezes until it's done, because nothing else can run while the thread is busy.

A Web Worker is a real, separate thread the browser spins up for you. You send it a script; it runs independently of the main thread, with its own global scope. The two sides talk by passing messages, not by sharing variables — there's no shared memory to worry about, just postMessage out and an onmessage handler on the other end.

See it in a real thing: a heavy computation that would otherwise jank the UI

Say you need to check if a large number is prime, and you don't want the button click that triggers it to freeze the page while it runs.

// worker.js — runs on its own thread
self.onmessage = (event) => {
  const n = event.data;
  let isPrime = n > 1;
  for (let i = 2; i * i <= n; i++) {
    if (n % i === 0) {
      isPrime = false;
      break;
    }
  }
  self.postMessage(isPrime);
};

// main.js — runs on the main thread
const worker = new Worker("worker.js");

worker.postMessage(999999999989); // send the number to check

worker.onmessage = (event) => {
  console.log("Is prime:", event.data); // the page never froze while this ran
};

While that loop is grinding away inside worker.js, the main thread is completely free — the user can still scroll, click, and type. When the worker finishes, it posts the result back, and main.js's onmessage fires with it, the same way any other async callback would.

What people usually miss

Watch out

• Workers cannot touch the DOM. No document, no window, no direct access to the page at all — a worker's whole job is to compute and message back, and the main thread does anything DOM-related with that result.
• Communication is always async and copy-based. There's no shared variable between a worker and the main thread — every postMessage call is a message being cloned across a boundary, not a direct reference to shared state.
• Spinning up a worker has real overhead. Creating one isn't free — for a one-off cheap calculation the setup cost isn't worth it. Workers earn their keep on genuinely heavy, blocking work, not everything.

The genealogy: another way to dodge a blocking main thread

The event loop lesson explains why one long synchronous task starves everything else queued behind it. A Web Worker sidesteps that problem entirely by moving the heavy work off the main thread rather than just scheduling it cleverly on it — which is a different fix from something like setTimeout chunking, which still runs on the same single thread and just yields between pieces.