Web Workers vs Service Workers
Slap yourself if
You think both are just 'background threads' or assume Service Workers are a superset of Web Workers.
Why this exists
Because teams routinely choose the wrong worker model, ship unnecessary complexity, and then fight bugs caused by fundamentally different lifecycles, scopes, and execution guarantees.
Mental model
Web Workers are compute isolation. Service Workers are network and lifecycle control. They solve orthogonal problems and overlap only superficially.
- Web Workers execute JS off the main thread with no DOM access.
- They live as long as their owning page or reference exists.
- Service Workers run independently of any page.
- They intercept network requests and respond via event-driven lifecycles.
- Using Service Workers for heavy computation.
- Expecting Web Workers to persist across page reloads.
- Treating both as long-lived background processes.
- Debugging lifecycle bugs as if they were threading issues.
Web Workers provide off-main-thread computation scoped to a page, while Service Workers provide event-driven control over network requests and caching across page lifecycles.
- Calls Service Workers 'background threads'.
- Assumes shared lifecycle semantics.
- Ignores install/activate phases.
- Mentions performance without scope or lifecycle.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.