Debounce vs Throttle

Both limit how often a function runs when it is called repeatedly, but they limit it in different ways.

Debouncing waits for the calls to stop. Each new call cancels the pending one and starts the clock again, and the function runs once, after the last call, with the arguments from that last call. The classic example is a search box that only queries the server once the user has stopped typing.

Throttling caps the rate. The function runs immediately on the first call, and then further calls within the window are dropped until the window expires. The classic example is a scroll handler that has to do work on every scroll event but may only do it a few times a second.

// Debounce: run only after the calls stop.
const debounce = (fn, waitMs) => {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), waitMs);
  };
};

// Throttle: run at most once per interval.
const throttle = (fn, waitMs) => {
  let blocked = false;
  return (...args) => {
    if (blocked) return;
    blocked = true;
    fn(...args);
    setTimeout(() => { blocked = false; }, waitMs);
  };
};

That difference shows up in the timing. The debounced function does not run at all until the calls stop, so it never runs mid-burst. The throttled function runs at the start of the burst and then stays quiet for the rest of the window.

There is also a trailing variant of throttle, which runs the function once more at the end of the window with the most recent arguments, and that is often what you actually want for something like a scroll handler, where you want the final position to be handled as well.

The choice follows from what you are trying to avoid.

Debounce for work that should happen once the user has finished. A search box that fires a request per keystroke, a form that validates when you stop typing, a chart that redraws after the window has been resized, and a save action that waits until the user pauses. The pattern is: the last event wins, and everything before it is wasted.

Throttle for work that must happen regularly but not too often. Scroll and resize handlers that update a layout or a progress bar, an analytics beacon that should not fire on every pixel, and a drag interaction that has to redraw at a manageable rate. The pattern is: a bounded rate, with the first event taking priority.

There is a third option worth mentioning, which is a throttle that also runs on the trailing edge. That combination is often the best of both, because you get an immediate response and you also handle the final state of the interaction.

Four pitfalls to raise in an interview. Debouncing delays the first response, which feels unresponsive if the wait is too long, so keep the window short enough that it still feels instant. Throttling on the leading edge drops the final event, which is why the trailing variant exists. Both need to be cleaned up, because a timer left running after a component is gone is a leak and a source of errors on an unmounted page. And neither of them changes the underlying problem: if the work itself is slow, limiting how often it runs only limits how often you notice the slowness.