What workers are and why they exist

Parse a 5 MB JSON file on the main thread and the page freezes for ~150 ms — dropped frames, dead buttons. The browser’s answer is not “make the thread faster.” It is “give you more threads.”

The main thread problem

The browser has one thread for JavaScript, layout, paint, and input. While it is busy, nothing else runs. Parse a large file, run a crypto hash, or filter a huge dataset on the main thread and every animation and button response stalls for the duration.

The browser’s answer is off-main-thread execution — workers. Four kinds exist, each for a different job:

• Web worker — a second JS thread for CPU-bound work (parsing, crypto, image processing). No DOM, no window, no document.
• Service worker — a network proxy sitting between the page and the server. Intercepts requests, serves cached responses, survives page close.
• Worklet — a tiny hook into the browser’s render or audio pipeline (paint worklet, audio worklet). Even more constrained than a worker.
• SharedArrayBuffer — shared memory between threads (not a worker itself, but the escape hatch from message-passing). Gated behind cross-origin isolation headers.

The office metaphor

The main thread is you at your desk: you answer the phone (input) and update the whiteboard (DOM) yourself. A web worker is a colleague in a back room — you send a big calculation by note, they do it without disturbing your desk, they send the answer back by note. They cannot touch your whiteboard. Only you can.

A service worker is the mailroom: every letter in or out passes through it first, and it can answer some from its own filing cabinet without going outside. It keeps running even when you leave for the day.

Bea · Browser uploads a photo to edit. Sven · Origin server narrates: “Applying the filter is millions of pixel operations — on the main thread, a 600 ms freeze. So we post the image data to a web worker. The worker churns the pixels on its own thread; the main thread stays free. It posts the result back and we paint it.”

The fundamental rule

Workers have no DOM. A worker’s global is WorkerGlobalScope — it has no document, no window, no elements. This is not a limitation to work around; it is the design. It keeps the DOM single-owner and race-condition-free. A worker can compute what to render and post the result back, but the main thread must apply it.

The one exception: OffscreenCanvas. A canvas bitmap is not part of the DOM tree — it is just a pixel buffer. You can transfer an OffscreenCanvas to a worker, and the worker can draw into it entirely off the main thread. Everything else in the DOM stays main-thread only.