Run-to-completion on one thread

One watchmaker works on one open watch at a time and closes it before touching the next.

At the bench	In the page
the watch open on the mat is finished before any other is picked up	run-to-completion (step 2)
watches handed in meanwhile go onto the side tray in the order they came, none refused, none merged	callbacks queued (step 3)
a full overhaul keeps every watch on the tray waiting	a long task (step 7)
staring at the tray for a spare part only he can unpack, so he never unpacks it	a busy-wait on a flag (step 8)
a customer who withdraws a watch still on the tray takes it back unopened, however long it has waited	clearTimeout on a due timer (step 10)
a second workshop with its own watchmaker, reached by notes across the counter	work done elsewhere: a Worker or a server (step 9)

In real terms: a page is only as responsive as its longest task; every click, message and timer waits for it to finish.

Breaks down when: a watchmaker can glance up and answer a customer mid-repair. A task cannot pause itself to let a callback run; it must return first (steps 2, 8).

Contrasting case: a microcontroller program, where a hardware interrupt pauses the main loop mid-statement to run its handler, so a shared counter needs interrupts switched off around each update. Nothing pauses a page's running task that way.

4.1 ExamHall: the proctor console freeze

EXH-1790: while a proctor re-sorted the candidate tiles by risk, the console froze. Flag alerts from the live feed, and the console's own heartbeat timer, appeared only when the sort ended, all at once. MR !1990 moved the scoring to the ranking service: the console posts the tile ids and applies the order the service returns.

sortButton.addEventListener('click', () => {
  setTimeout(sendHeartbeat, 100);           // falls due during the sort
  rescoreAndSortTiles();                    // before: on the page, one long task
});
// after MR !1990: the service scores the tiles; the page applies the order when the reply arrives
sortButton.addEventListener('click', () => {
  setTimeout(sendHeartbeat, 100);
  const req = new XMLHttpRequest();
  req.open('POST', '/rank');
  req.onload = () => applyTileOrder(JSON.parse(req.responseText).ranked);
  req.send(JSON.stringify(tileIds));
});

EXH-1790 sort in the click handler   while the sort computes: alerts 0 · heartbeat 0 | after it: alerts 3 (1 2 3) · heartbeat 1 | tiles re-ordered in the handler
MR !1990 sort on the ranking service while the service computes: alerts 3 (1 2 3) · heartbeat 1 | after it: alerts 0 · heartbeat 0 | tiles re-ordered from the service's reply (42,13,7)

Before the fix, the three alerts and the heartbeat waited behind the sort, then all ran (steps 3, 7). After it, the handler returned at once, so the page's thread was free while the service computed; each alert and the heartbeat ran on time, and the reply ran later as its own task (step 9). The script prints each source's own order only, because which queue runs first after a block is the browser's choice (step 6).

4.2 Catalog: two listeners and a 0 ms timer

"Apply filters" has two click listeners. The first sets a 0 ms timer, then recomputes facet counts for a second; the second logs the click.

applyButton.addEventListener('click', () => {
  setTimeout(() => log('0 ms timer'), 0);
  recomputeFacetCounts();                   // about 1 s, synchronous
});
applyButton.addEventListener('click', () => log('listener 2: analytics'));

listener 1: start -> listener 1: end -> listener 2: analytics -> 0 ms timer

The timer fell due almost at once, yet it ran last: one click's dispatch is one task, and both listeners belong to it (steps 4–5).