Debounce vs throttle

A reporter keeps phoning in corrections to an on-screen caption. The director airs the caption only after 5 seconds pass with no new correction. The stock ticker at the bottom of the screen refreshes every 10 seconds, whatever the number of trades.

In the control room	In the code
each new correction restarts the director's 5-second wait	each call clears and restarts the timer (step 2)
only the newest wording goes on air; older ones are thrown away	saved arguments are overwritten; the latest run (step 3)
the "air the first correction at once, then wait for quiet" rule	leading: true (step 4)
the producer's rule "whatever happens, air something every 30 seconds"	maxWait (step 4)
the ticker shows the newest price on a fixed beat while trades never stop; trades in between are not replayed	throttle: one run per window, intermediate calls dropped (step 5)
before a cut to an advert break, the director airs the pending caption now, or kills it	flush() / cancel() (steps 6–7)

In real terms: debounce runs fn once, with the latest arguments, after calls stop for wait ms; throttle runs it at most once per wait ms while calls continue.

Breaks down when: a director would still air the caption if the studio lost power; a timer in a closed tab never fires. Wrong inference: "the trailing save always happens eventually." It does not, which is why step 7 exists.

Contrasting case: a switchboard that relays every call 5 seconds late. Nothing merges, and four corrections produce four broadcasts. That is a plain setTimeout per call, not a debounce.

Every script uses limiters.mjs and a mock clock stepped 1 ms at a time, so every timestamp is exact.

4.1 ExamHall: autosave with flush on blur and on hide

EXH-371 was lost answer text: a candidate typed, then switched tab before the 800 ms quiet period ended, and the last words were never saved. MR !747 added the flush.

const saveAnswer = (draft) =>
  fetch('/attempts/a-7/answers/q4', { method: 'PUT', body: draft, keepalive: true }); // survives page unload
const autosave = debounce(saveAnswer, 800);
editor.addEventListener('blur', () => autosave.flush());          // candidate leaves the field
page.addEventListener('visibilitychange', () => {
  if (page.visibilityState === 'hidden') autosave.flush();         // the tab may never run another timer
});
// `page` stands in for document, `editor` for the <textarea>; the script's fetch is a stub that logs its request
type([[0, 'Dem'], [250, 'Demand'], [500, 'Demand fa'], [700, 'Demand falls']]);
type([[2000, 'Demand falls as'], [2200, 'Demand falls as p']]);
advanceTo(2400); editor.dispatchEvent(new Event('blur'));
type([[3000, 'Demand falls as prices'], [3200, 'Demand falls as prices rise']]);
advanceTo(3400); page.visibilityState = 'hidden'; page.dispatchEvent(new Event('visibilitychange'));
editor.dispatchEvent(new Event('blur'));                            // a second flush has nothing to send

t= 700  last key; pending=true
t=1500  PUT /attempts/a-7/answers/q4 "Demand falls" keepalive=true
t=2200  last key; pending=true
t=2400  blur (clicks the question list)
t=2400  PUT /attempts/a-7/answers/q4 "Demand falls as p" keepalive=true
t=3200  last key; pending=true
t=3400  tab hidden
t=3400  PUT /attempts/a-7/answers/q4 "Demand falls as prices rise" keepalive=true
t=3400  after both flushes; pending=false
t=5000  end: no saves at 3000 or 4000 (both flushed timers were cleared)

Four keystrokes cause one save, 800 ms after the last (steps 2–3). Blur and the hidden tab each save the pending draft at once and clear its timer, so nothing is sent at 3000 or 4000; the second flush sends nothing (steps 6–7). keepalive lets the PUT finish if the tab then closes.

4.2 ExamHall: the proctor console's scroll handler

The proctor console recomputes which candidate tiles are visible. A 2.5 s scroll sends 26 events, one every 100 ms. The same stream is run through four limiters:

for (let t = 0; t <= 2500; t += 100) { advanceTo(base + t); onScroll(t * 2); }  // scrollY = 2 px per ms

throttle 1000 (leading+trailing)      4 calls  0:y0 1000:y1800 2000:y3800 3000:y5000
throttle 1000 {leading:false}         3 calls  1000:y1800 2000:y3800 3000:y5000
debounce 1000                         1 calls  3500:y5000
debounce 1000 {leading:true}          2 calls  0:y0 3500:y5000

Throttle updates the tiles during the scroll (step 5); debounce updates them only 1 s after it stops (step 2). For a live view that is the whole difference. The final position (y5000) always arrives, because both keep the latest arguments.

4.3 Proof domain, catalog: search-as-you-type with maxWait and cancel

A shopper types wireless headph, one key every 200 ms (keys at 0…2800). A 300 ms quiet period never happens until they stop.

run('debounce 300', {});
run('debounce 300 {maxWait:1000}', { maxWait: 1000 });
// then: type "u", "us", "usb" at 0/100/200, clear the box at 350 and call search.cancel()

debounce 300                   3100:"wireless headph"
debounce 300 {maxWait:1000}    1000:"wirel" 2000:"wireless h" 3000:"wireless headph"
cleared at 350 + cancel()      sent: []

Plain debounce shows no results for 3.1 s. maxWait forces one request per second during the burst (step 4). cancel() drops the pending "usb" query, so an emptied box never fills with stale results (step 6).