Lesson 0001 · ~10 minutes
One skill: place workers on the concurrency spectrum and pick them only when the hard problem is long work blocking the UI thread.
After the quiz, you can defend “worker yes / worker no” in a design
review without writing a line of postMessage yet.
In a browser tab, one main thread does most of the job: your JavaScript, layout, paint, and handling clicks and scrolls. While a long JavaScript task runs, those other jobs wait. Users feel that as jank, frozen buttons, or laggy input.
Web Workers
let you run a script in a background thread so heavy
work does not freeze the UI thread. The worker thread can crunch
numbers, parse data, or call
fetch — but it cannot touch the DOM.
web.dev
calls this an off-main-thread (OMT) architecture: free the
main thread so the page stays responsive.
The normative model lives in the HTML Living Standard — Web workers.
On many platforms, threads share memory and you lock carefully. Web Workers are stricter by design:
postMessage
and message events. Data is
copied (structured clone), not casually shared.
That isolation is the whole system-design plot: you gain concurrency for compute, and you pay a messaging and architecture tax.
Ordered by “how far is this work from the UI thread?” — not by coolness.
Default. Fine for short work. A multi-second parse here freezes scroll and clicks.
Break long main-thread work into slices so the browser can paint and handle input between chunks. Still one thread — no parallel CPU.
One owner script, separate thread. Ideal for CPU-heavy, non-DOM work (parse, compress, image pipeline, game logic).
One worker shared across tabs/windows of the same origin. Reach for it when the hard problem is multi-context coordination — later lessons.
Different job: network proxy, offline, push. Same “worker” word — not a substitute for “move my big loop off the UI.”
MDN’s overview of worker types matches this map: dedicated, shared, and service workers solve different problems.
If the hard part is “this pure compute or data work steals the main thread long enough to hurt interaction” and it does not need the DOM, start with a dedicated worker. If the hard part is “keep the UI thread free while something slow runs” but the work is short enough to yield, chunking may be enough. If the hard part is “intercept network / offline”, that is a service worker — different tool.
| Signal | Leans dedicated worker | Leans away |
|---|---|---|
| Work shape | CPU-heavy, pure data, long tasks | Mostly DOM, layout, animation, tiny helpers |
| UI needs | Main thread must stay interactive during work | Blocking for <~frame is fine; keep it simple |
| Data flow | Clear input → result messages | Constant huge copies that cost more than the work |
| Ownership | One page/script owns the task | Many tabs must share one long-lived process → shared worker later |
| Classic fits | Image/codec, large JSON/CSV parse, crypto, WASM, game logic | Toggling a class, small form validation, “use SW for offline” |
Moving work to a worker does not delete the work. Surma’s “When should you be using Web Workers?” and the web.dev OMT guide stress resilience and UI responsiveness — not free speed. Messaging has cost; tooling and mental model have cost. You choose workers to protect the main thread under unpredictable device performance.
Choose the best default. Options are matched for length so formatting does not hint. Feedback is immediate.
Photo editor: applying a filter to a large image freezes the UI for several seconds on mid-range phones.
Signup form: validate email format on every keystroke; work is under a millisecond on any device you care about.
Product goal: the app must work offline and serve a shell from cache when the network is down.
Analytics dashboard: user uploads a 40MB CSV; parsing blocks the main thread for 2–4 seconds.
web.dev — Use web workers to run JavaScript off the browser’s main thread (Surma). Best short primary for this lesson’s OMT framing and honest tradeoffs. Optional depth: When should you be using Web Workers?.