[whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

[Jonathan Zuckerman]

You’re probably aware there are libraries that offer functionality of this
sort (debounce and throttle in underscore/lodash is the one I’m most
familiar with) and the web community seems content to add a small
dependency when such functionality is required. How would you convince
browser vendors to implement this?
On Mon, Nov 27, 2017 at 18:05 Sylon Zero <sylonzero at gmail.com> wrote:

> *Core Problem Statement* Processor functions that subscribe to events via a
> topic string may need to be prioritized for processing based on the topic
> itself. Conversely, certain events may be more numerous but should not
> limit the ability of the JS environment to respond and process other
> events, that may be more critical to either the User Experience (UX) or
> integrity of the system (e.g. events that trigger saving data to a
> back-end).
>
> *Background Information* As Browser/CommonJS environments bring paradigms
> like UI event handling and back-end event handling into the same problem
> space, it is useful to apply common patterns used in Message-based
> Publish-Subscribe environments with message brokers, which is what the JS
> execution context often behaves as. The use case here is to ensure that one
> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
> or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
> massive differences in event volume or conversely, expensive operations
> that block the execution thread in question.
>
> *Proposed Solution* Add metering options to the addEventListener
> *Options* configuration
> object. These options control how the JS execution environment controls the
> throttling/firing of event handler instances in response to events that
> match the topic string of the subscription created by addEventListener.
>
> Proposed options:
>
>    - maxInstances [Number / Function] used to decide how many event
>    listeners can be invoked before throttling occurs. Throttling does not
> lose
>    events but simply queues them.
>    - throttlingQueueLength [Number] used to maintain an in-memory queue of
>    un-processed events per Topic string, after throttling kicks in.
>    - throttlingQueuePolicy [String] Values could be exception - throws an
>    exception when the queue length is exceeded, rolling - drops the oldest
>    events and pushes newer ones into the queue, expand- allow the queue to
>    expand to cover all events.
>
> *Additional Options* It might be even more useful if the options allowed
> targeting or creation of Web Workers (or Node child processes, depending on
> the execution context) based on the event handler configuration. This could
> potentially target CPU cores and/or O/S child processes / threads
> (depending on the O/S terminology for parallel execution).
>
> *Related Thread* The proposal identified in the link below (by Šime
> Vidas) could
> be part of this solution as it defines other metering options around
> debounce (which improves scale around event handling, which is in the same
> problem space) and handling throttling through frequency, which should be
> one of the alternatives in addition to my proposal above (as I believe they
> are orthogonal): https://discourse.wicg.io/t/add-event-throttlin
> g-and-debouncing-to-addeventlisteneroptions/2436/19
>
> Sai Prakash
> @SylonZero
>