Browser & Frontend Runtime

Workers: free-recall review

Crux Free-recall prompts across the workers unit. Answer each in your own words first, then reveal the model answer and compare against the senior-depth version.

Your altitude — climbing toward senior

ZeroJuniorMiddleSenior

You are at senior altitude — in orbit

◷ 14 min

Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of reconstructing the mechanism is what makes it stick.

Goal

Reconstruct the unit’s spine without looking back — the DOM boundary, clone vs transfer cost, the service-worker lifecycle and its waiting trap, the COOP/COEP gate on SharedArrayBuffer, and the rules for sizing and shaping a worker pool.

Recall before you leave

01
Why can no kind of worker touch the DOM, and what is the one carve-out?
02
Compare structured clone and transfer: what each costs, and when to use SharedArrayBuffer instead.
03
Walk the service-worker lifecycle from register() to fetch, and explain the waiting state.
04
State everything required for SharedArrayBuffer to exist, and the cost of enabling it.
05
How do you size a worker pool, and what two controls keep it safe under load?
06
What is the Comlink task-hop problem and how do you design worker interfaces around it?

Recap

If you could reconstruct each answer from memory, you hold the unit’s spine: workers never touch the DOM (OffscreenCanvas is the only carve-out), postMessage clones at ~1 ms/MB while transfer hands off in O(1) and SharedArrayBuffer shares concurrently behind COOP+COEP, the service-worker lifecycle waits before activating to avoid version skew, SAB requires cross-origin isolation and an audit of every cross-origin asset, and a pool sized to hardwareConcurrency − 1 stays safe only with backpressure, priority routing, and coarse (task-hop-aware) interfaces.

Continue the climb ↑Workers: code and snippet reading