Lesson 18 of 80

Debounce & Throttle

Q: Implement debounce and throttle, and explain when you'd reach for each.

A strong answer covers: Debounce: clearTimeout on every call, reschedule — only the last call in a burst fires, after a quiet period; Throttle: track last-run timestamp, only invoke if enough time has elapsed since the last actual call; Correctly matches use case to pattern: debounce for search-as-you-type (wait for pause), throttle for scroll/resize (need regular updates during continuous activity).

Two closure-based patterns for taming a noisy stream of events — one waits for quiet, the other enforces a steady maximum rate.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A user types 5 characters quickly into a debounced (300ms) search box, then stops. How many times does the debounced function actually run?

Once, 300ms after the last keystrokeFive times, once per keystrokeZero times — debounce cancels all pending calls permanently

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Debounce & Throttle

What interviewers actually ask about this, and what a strong answer has to cover.

Implement debounce and throttle, and explain when you'd reach for each.

A strong answer covers

Debounce: clearTimeout on every call, reschedule — only the last call in a burst fires, after a quiet period
Throttle: track last-run timestamp, only invoke if enough time has elapsed since the last actual call
Correctly matches use case to pattern: debounce for search-as-you-type (wait for pause), throttle for scroll/resize (need regular updates during continuous activity)

Likely follow-ups

What's the difference between leading-edge and trailing-edge debounce?
Can you implement throttle so it also guarantees a final trailing call after the last event?
What underlying pattern do debounce, throttle, and memoize all share?

Practice these with the AI interviewer →

The plain-language idea

Both wrap a function to control how often it actually runs, but they solve different problems:

Debounce — "wait until things go quiet, then run once." Good for search-as-you-type: don't fire a request on every keystroke, fire one after the user pauses.
Throttle — "run at most once every N milliseconds, no matter how often you're called." Good for scroll/resize handlers: you want regular updates, not silence followed by one final burst.

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);                      // cancel the pending call
    timer = setTimeout(() => fn(...args), delay);
  };
}

function throttle(fn, interval) {
  let lastRun = 0;
  return function (...args) {
    const now = Date.now();
    if (now - lastRun >= interval) {
      lastRun = now;
      fn(...args);                             // run immediately, then go quiet
    }
  };
}

Both are closures over per-instance state (a timer id; a last-run timestamp) — the same mechanism as memoize's cache, just applied to timing instead of results.

Debounce vs throttle: the same burst, two outcomesStep 1 of 4

Five raw calls arrive close together — a user typing fast, or a scroll event firing repeatedly.

What people usually miss

Watch out

Debounce's clearTimeout is the whole trick. Every new call cancels the previous pending timer and starts a fresh one — only the last call in a burst ever actually survives to fire.
"Leading" vs "trailing" edge — the debounce above fires after the pause (trailing). Some implementations also support firing immediately on the first call (leading), then ignoring the rest of the burst.
Neither is free — both still register every event; they just control how often the expensive handler runs, not how often the raw event fires.

Why this matters in interviews

"Implement debounce" (and its sibling "implement throttle") is one of the most common live-coding exercises in frontend interviews specifically because it checks closures, timers, and precise control flow all in about eight lines.