Web Workers for Heavy Data Tasks: Keeping the UI Alive

Your CSV parser works perfectly — it just locks the page for nine seconds while it runs. No progress bar updates, no cancel button responds, the tab offers to kill itself. The computation is fine; the thread is wrong. Browsers give JavaScript one main thread for UI and events, and any data task that hogs it punishes the user for your architecture. Web Workers are the fix: real background threads with a message-passing API, available in every modern browser.

What Moves to a Worker

The rule is simple: anything that takes longer than ~50ms and does not touch the DOM belongs in a worker. For data tools that means parsing (CSV, JSON, XLSX), statistics (aggregations, quantiles, correlations), and inference (scoring rows through a model). The main thread keeps rendering progress, handling cancel, and staying alive; the worker crunches. Chunk the input and post progress messages per chunk — a determinate progress bar is the difference between "slow" and "broken" in the user's mind.

Structure the worker as a small job runner: it receives { jobId, type, payload }, posts { jobId, progress } updates, and resolves with { jobId, result }. One generic worker script can host parsing, stats, and export jobs behind a type switch — far easier to maintain than a worker per task, and it keeps the main-thread API to a single runJob() promise.

Transferables: Skip the Copy

Messages to workers are copied by default (structured clone). For a 50MB parsed table, the copy itself becomes the freeze you were trying to avoid. The escape hatch is transferable objects: pass an ArrayBuffer in the transfer list and ownership moves to the worker with zero copying. Design worker payloads around buffers — parse to typed arrays or serialize to a buffer — and the handoff stays O(1) no matter the data size.

Two companion techniques: chunked processing inside the worker (process N thousand rows, post progress, yield with setTimeout(0) so cancel messages get heard), and result streaming for huge outputs (post partial aggregates rather than one giant result). These are the same responsiveness patterns behind large-file parsing — workers are the thread they run on.

Fallbacks and Limits

Workers cannot touch the DOM, share little state, and are unavailable in a few exotic contexts (some sandboxed iframes, very old browsers). Engineer the fallback deliberately: feature-detect window.Worker, and when it is missing, run the same job function on the main thread in small time-sliced chunks with progress UI — slower, but never frozen. Debug with the same discipline: worker errors surface as messageerror events with unhelpful payloads, so wrap worker entry points in try/catch and post structured { error } messages back.

The payoff is architectural, not just cosmetic: once heavy work lives in workers, the main thread stays a thin UI shell, and features like cancel, progress, and concurrent jobs become natural instead of heroic. That is the shape client-side ML demands — inference must run off-thread — and it is why every serious browser data tool eventually converges on the same design: workers do the work, the page does the talking.