2.0-alpha Menu

delay vs debounceTime

If your stream is created from key presses or mouse movements, you’ll likely deal with bursts of events. But you can’t react to every single event, as it would overload the CPU or flood the servers with too many requests.

A strategy is to wait for a certain “emission silence” window of time (where the user has stopped typing or moving his mouse) to actually handle the latest word or mouse position.

To do so, you can use ❚ debounceTime. Like delay, it waits for a certain time period and delays events. But debounceTime can also ignore events.

They both accept a time period argument, such as 3000 milliseconds.


This is how ❚ debounceTime operates:

  • Whenever an event is emitted, the period of silence measured restarts from zero
  • The card waits for a “time period” silence and then emits the latest value of the input stream
  • As a result, it returns a new stream of debounced events

debounceTime is a rate-limiting operator. It ignores events but also delays others.


This is how ❚ delay operates:

  • It projects each event of an input stream through time
  • As a result, it returns a new stream of timeshifted events

Trying different time periods

The time period is small enough that no events are ignored

With a 3000ms time period, some events are ignored

As the time period gets larger, even more events are ignored


debounceTime vs throttleTime

See also

scan vs reduce

💌 I create something new each week!
Learn Reactive Programming and stay tuned.

Occasional updates, plus:

Cédric Soulas - Freelance Developer Advocate. Learn more.

Follow 👨‍💻 Hire me