Debounce vs Throttle Visualizer — Free JS Snippet

Debounce and throttle are the two most commonly confused timing functions in frontend JavaScript, and most explanations of the difference are purely verbal — "debounce waits for a pause, throttle limits the rate" — which is accurate but forgettable, because you never actually see the behaviors happen. This snippet feeds a single shared stream of rapid-fire events into two lanes at once, each wrapping the exact same raw event with a real, correct implementation of debounce or throttle, and plots every raw event as a small tick alongside a taller, differently colored mark for every actual function fire. Run the same burst through both lanes and the fire count difference — debounce firing once, throttle firing several times — becomes something you watch happen, not something you have to take on faith.

The debounce implementation, and why it has to clearTimeout on every call

debounce(fn, wait) closes over a single timer variable. Every time the returned wrapped function is called, it unconditionally calls clearTimeout(timer) before scheduling a new setTimeout. This is the entire mechanism: a rapid burst of ten calls 35ms apart never lets any of the first nine timers survive long enough to fire, because each new call cancels the previous pending timer before it can complete. Only once 300ms pass with *no new call arriving to cancel it* does the very last scheduled timer actually run. This is why the visualizer's debounce lane shows a cluster of raw ticks tightly packed together, followed by exactly one green fire mark sitting 300ms after the *last* tick in the cluster — not 300ms after the first.

The throttle implementation, and the trailing-edge detail most simplified versions skip

throttle(fn, wait) is more involved than debounce, and this is deliberate: a naive throttle that only checks "has enough time passed since the last fire" and otherwise does nothing will silently drop the final value of a burst if the burst ends mid-window. This implementation tracks lastFireTime and computes remaining = wait - (now - lastFireTime) on every call. If no time remains, it fires immediately (the "leading edge") and updates lastFireTime. If time does remain, instead of just discarding the call, it stores the latest args as pendingArgs and — only if no trailing timer is already scheduled — schedules one to fire exactly when the window ends (the "trailing edge"), using the *most recent* arguments captured by that point. This guarantees the throttled function always reflects the latest input by the time the window closes, rather than potentially firing with stale, outdated arguments from earlier in the burst.

Why the two lanes share one event source

Both lanes are driven by the exact same onRawEvent() function, called once per raw slider input event or once per tick of the "Fire 10 events quickly" burst. Every single raw event is passed to *both* debouncedFn() and throttledFn() in the same call. This matters for the comparison to be honest: if the two lanes were driven by separately generated random event streams, any difference in fire count could be attributed to different input rather than different timing behavior. By construction, both wrapped functions here see literally identical input, so the entire difference in how many times each one fires is attributable purely to the debounce-versus-throttle logic itself.

Plotting real elapsed time, not just counting events

Every mark's horizontal position is computed from xPercentForNow(), which measures real elapsed milliseconds since the timeline was last reset against a fixed LANE_MS window (6 seconds), not from a fixed per-event pixel spacing. This means the visual gap between the raw ticks in a burst and their eventual fire mark(s) is an honest representation of the actual 300ms wait — if you fire the burst slowly by hand instead of using the button, the ticks visibly spread further apart and the debounce fire mark visibly follows further behind the last one, exactly matching the real timing.

Why the fire count is the crux of the whole comparison

For a burst of ten rapid raw events, debounce ends the burst having fired its wrapped function exactly once — after the last event plus 300ms. Throttle, wrapping the identical burst, fires near the very start (leading edge) and, if the burst duration exceeds the 300ms window, potentially a second time at the trailing edge — always at least once, and typically more than debounce's single fire for the same input. That fire-count difference for identical input, plotted side by side with visibly different-colored taller marks, is the entire point of the snippet: it is not asserted in prose, it is counted and displayed live in each lane's header.