Summary

  • W3C's first Web Workers Working Draft appeared on 23 April 2009. It let a page start a script in a separate parallel execution environment and coordinate with it by passing messages.
  • The draft's prime-number example put a costly loop in a worker. The worker sent each new result to the page, and the page displayed it while its own interaction scripts remained available.

Imagine asking a web page to find prime numbers. At first it obliges. Then the calculation grows, the cursor still moves, and the button you just clicked behaves like a clerk who has gone behind a door marked “back in five minutes.” The browser may be busy doing exactly what the page asked. The person in front of it has no useful way to tell.

The Web Workers Working Draft issued by W3C on 23 April 2009 took that problem straight to its introduction. It defined an API for background scripts running independently of scripts that respond to clicks and other interactions. The document's deliberately plain example computes prime numbers. The main document starts a worker; the worker searches and sends the latest prime back; the page displays progress. A reader can keep dealing with the front desk while the arithmetic happens in the back room.

The separation has a specific shape. A page creates a Worker from a script URL. The browser runs that script in a separate parallel environment. The page and worker use postMessage and message handlers to exchange data. The worker has its own execution context; the page retains the interface. The worker sends a number, and a handler in the page changes what the reader sees. The computation does not need to reach into the page and rearrange its buttons.

The draft's sample is almost rude in its simplicity. The page creates new Worker('worker.js') and waits. There is no form to submit and no job ticket to issue: the worker starts an endless, rather clumsy hunt for primes as soon as its script runs. Each time it finds one, postMessage(n) sends the number out. The page's onmessage handler puts event.data into an <output> element. The worker can spend all day testing divisors; it never gets to seize the page's display. That last handoff belongs to the page.

That message boundary was the architecture, not an inconvenience tacked on to it. The December 2009 Last Call draft described thread-like operation with message passing as the coordination mechanism. The page could ask for work and receive results without handing a long calculation the same moment-by-moment attention it needed for a click. A message can carry the answer or a progress update. It also gives the page a place to decide what to display, when to discard an old result, and whether the reader has already moved on.

The prime-number loop makes the contrast especially sharp. Nobody needs an urgent answer to the next prime in a browser demo. That is why the example is useful. It strips away network latency, database queues and server excuses. The page freezes because its own computation monopolizes the place where interaction happens. Move the loop to a worker, let it report back, and the interface can continue to listen. The latest number appears when it arrives; the click does not have to wait behind it.

There is a catch in the example that makes it better journalism than a perfect demo would be: the worker does not finish. It keeps searching. The page never receives a ceremonial “done” message and never needs one to stay usable. If a reader leaves, the application has to decide how to stop or abandon work that has outlived its audience. Moving the loop out of the way solves the frozen-button problem; it also makes ownership of long-running work an explicit design choice.

Workers had a price. The same 2009 Last Call text warned that they were relatively heavy, with startup and per-instance memory costs. It gave an admirably absurd example: launching one worker for each pixel of a four-megapixel image would be a bad plan. Background work was a tool for a meaningful task, not a free assistant summoned for every dot on the screen. The prime factory still needed a sensible manager.

The model grew more precise as the draft matured. The 2012 Candidate Recommendation snapshot kept the dedicated worker and shared-worker distinction. A dedicated worker communicates with its creator through an implicit channel; shared workers can accept connections from more than one same-origin context through ports. The 2015 Working Draft explained Worker creation, onmessage, postMessage and the explicit MessagePort used by a shared worker. The page and its helper had a postal service, and each kind of helper had an address.

This was a different boundary from the one that organized browser storage. A value in sessionStorage belongs to a window and an origin; a long calculation in a worker belongs to a separate execution environment. The two problems can appear on the same page. A travel site might remember a booking in one place and perform a costly search in another. Good software gives the data and the work their own addresses, then states clearly how results return to the person who asked.

The W3C publication record traces the Web Workers document from the April 2009 draft through the later Candidate Recommendation snapshot and 2015 draft. The original prime example still reads like a tiny service manual for respect. The page should keep listening. The background calculation should report what it has found. Neither side needs to pretend the other has vanished.