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

David,

To clarify your message: it sounds like it is primarily feedback to
Jonathan about the fact that a wide range of use cases and awareness of
options exist in the Web community at large, and also that some of the
existing options in the addEventListener parameters are useful even though
one may be able to handle some of those using custom code. Is that a fair
summary of your points?

I wanted to make sure I didn’t miss out on any feedback you were giving on
the proposal itself.

- Sai.

On Fri, Dec 1, 2017 at 4:36 AM David Bruant <bruant.d@gmail.com> wrote:

> Le 28/11/2017 à 00:48, Jonathan Zuckerman a écrit :
> > 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.
> With all due respect, i think it's dangerous to start a sentence by "the
> web community" given how broad and ever-changing this group of human
> beings is.
>
> For one data point, it's been 6 years that i regularly give advanced
> JavaScript trainings to people who are already JS practitionners and
> they don't know about the concept of event queue and barely about basic
> perf advices (reduce round trips to a minimum, minimize the size of
> what's sent, etc.). Debounce/throttling is further down the road.
>
> By the logic of "the web community seems content to add a small
> dependency", the 'once' option [1], probably shouldn't have seen the
> light given how easy it is to rewrite. Same for 'passive'. Same for
> Element.prototype.remove ("DOM4"). etc.
> I'm glad they exist though.
>
> David
>
> [1]
>
> https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
>
> > How would you convince
> > browser vendors to implement this?
> >
> >
> > On Mon, Nov 27, 2017 at 18:05 Sylon Zero <sylonzero@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
> >>
>
>

Received on Friday, 1 December 2017 20:56:12 UTC