# Mission: Web Workers

## Why
As a frontend engineer, you want durable judgment about **off-main-thread work** — not a one-off `new Worker` tutorial. When a feature risks jank, heavy compute, or multi-tab coordination, you should decide whether a worker belongs in the design, which kind, and what tradeoffs you accept — and defend that choice in design reviews.

## Success looks like
- Given a product/perf requirement, decide main-thread vs dedicated worker vs shared worker (and when service workers are a different tool)
- Explain the concurrency model: isolated threads, message-passing, no shared DOM
- Spot deal-breakers early (DOM access, structured-clone cost, lifecycle, debugging, tooling)
- Defend the choice in a design review with clear constraints
- Complete light hands-on exercises that lock the mental model (not a production worker-pool framework)

## Constraints
- Frontend-first: system design decisions and browser APIs, not deep OS threading theory
- System-design lens; short interactive lessons (same shape as the SSE track)
- **Decisions + light hands-on** — not decision-only, not full architecture depth
- Path: **dedicated workers first**, then shared workers; service workers as comparison labels only
- Zero prior Web Workers experience — start from the main-thread problem
- No urgent product deadline — optimize for retention and decision quality

## Status
**Core mission complete** (lessons 1–6 + references). Decision fluency is the bar; optional later depth: hands-on lab, transfer pipelines, Comlink-style RPC.

## Out of scope
- Full Service Worker / PWA offline architecture (comparison only)
- Worklets (audio/paint/layout) beyond brief “related but different”
- Native threads, Node `worker_threads`, or Deno workers as primary focus
- Shipping a production worker pool / Comlink-scale framework (may mention libraries later)