Web Workers & Parallelism

The browser's main thread handles JavaScript execution, layout, paint, and user input in a single-threaded event loop. Understanding why this design exists and when it becomes a performance cliff is the foundation for every parallelism strategy.

Dedicated Workers give you a separate OS thread for JavaScript execution. Understanding their lifecycle — creation, message passing, error handling, and termination — plus when to use module workers and libraries like Comlink is what separates toy demos from production-grade parallelism.

Structured clone copies data. Transferable objects move ownership without copying a single byte. Understanding which types are transferable, how transfer works at the memory level, and when the zero-copy advantage disappears is critical for high-performance worker communication.

Beyond simple worker.postMessage, the browser provides MessageChannel, BroadcastChannel, SharedWorker, and service worker messaging for complex multi-context architectures. Understanding which channel to use — and when simple postMessage is enough — separates production systems from tutorials.

SharedArrayBuffer gives multiple threads access to the same memory. Atomics provides synchronization primitives to prevent data races. Together they enable true shared-memory parallelism in JavaScript — with all the dangers and power that implies.

OffscreenCanvas lets you render graphics in a Web Worker — decoupling canvas drawing from the main thread. This keeps the UI responsive while running complex visualizations, image processing, or WebGL rendering at full frame rate.

Toy demos use one worker for one task. Production systems need pooling, task scheduling, graceful degradation, error recovery, and integration with frameworks like React and Next.js. These are the patterns that separate prototypes from production-grade parallelism.