Add event throttling and debouncing to AddEventListenerOptions


These proposals fail to think about what happens when multiple event listeners are added and there are handlers that don’t throttle/debounce the events. What is the dispatching model?

If certain code requires throttled events and other code doesn’t you want the UA to keep track of each event listener state? That is a complex model to store.

In the case of pointermoves Chrome “throttles” these to match the display frequency. In fact they are sent just before rAF time so that we eliminate unnecessary work.


I don’t know how browsers implement this, but my guess is that they would need to postpone invoking handlers that have the debounce option until after the event has stopped firing (in my proposal, the browser would decide what that interval is).

I don’t know how complicated this is to implement. My job is to compile use cases (see my original post above for the list), and then the browsers can decide if it’s worth implementing this in order to free developers from having to use libraries for event debouncing.

See the use case for throttling in my original post, where I give an example of when throttling to 60 FPS is not enough.


This problem is also solved by using a JS class. You can just add an event listener like this:

document.addEventListener("pointermove", e => rateLimiter.Call(e));

Then the browser doesn’t need to worry about any of the complexity of how to dispatch the events.


I am fairly certain that browsers can implement event debouncing just fine, so we needn‘t worry about them. What we do need to worry about are standard APIs that aren‘t sufficient for creating performant web apps.

Case in point: Eric Bidelman has shared a component that fires resize events when it’s resized. His tweet has been retweeted and liked hundreds of times. Developers certainly seem to like this type of feature. However, the component taxes my fairly powerful CPU. This is unacceptable. We need to fix this by enhancing the standard APIs, so that they can be performant by default.

This is not about the individual preferences of your (or anyone else’s) large app. This is about the web platform. It needs event debouncing, so that we can have performant apps by default. I have compiled a list of 3 use cases for event debouncing in my original post. I think, that’s enough to start discussing a potential API. Specifically, should the debounce option be a Boolean or number?


What about if you want to change the debouncing options, such as to disable it, or alter the timeouts in response to user settings or activity? With the event listener API is it intended that the event has to be entirely removed and re-added with new settings? That will have other subtle side-effects like possibly re-ordering its firing sequence relative to other listeners, as well as requiring re-specifying all other event listener options at the same time (passive, capture etc).

Performant by default is of course a worthy goal, but it seems to solve a lot of problems, apply to more cases (e.g. pure JS events), and make it more flexible and future-proof if you move this in to JS land. We could look to standardise a JS class to do this, but then by that point, why not just write a library? Specs are great, but once v1 ships they become difficult to change, and in the long term can end up as a backwards-compatibility headache. Libraries avoid all of that. So in my opinion, generally anything that can be a library, should be.


An event handler is bound to its debouncing option. I’m not sure for what reason an app would need to change this subsequently.

Note that the proposal is a JS API, so we’re already in JS land. I think, I’ve already answered your question. The web platform needs to have APIs that are performant by default, without libraries. In the use cases I’ve described in my original post, the standard APIs cause performance issues. Currently, you just cannot handle certain events without wasting the user’s CPU.