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

[Garrett Smith]

.
> 
>> On Fri, Dec 1, 2017 at 4:36 AM David Bruant  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

Maybe there should be events for onscrollend and onresizeend. 

How that end is determined, e.g. via gestures, mouse, or keyboard shortcuts, 
can be spec’d and implementation details to be be obscured away by the browser. 

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

[Sylon Zero]

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  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  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): 

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

[David Bruant]

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  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

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

[Jonathan Zuckerman]

>From my own experience, only about half of the times I’ve required debounce
or throttle has been related to event handling, so if your proposal was
accepted I’d still need to include a library to satisfy the other scenarios.
On Tue, Nov 28, 2017 at 00:01 Sylon Zero  wrote:

> I think libraries having those functions emphasizes the point here, as
> that validates the existence and need for those patterns which then raises
> the requirement: should this be native to the browser?
>
> I believe the answer is yes, given how much work has already been put into
> standardizing the resource/computation model around the browser (web
> workers, local storage, etc) which is architecturally, IMHO, a related
> effort. Those capabilities come to life when there are smarter ways to
> utilize and route work to them through built-in features related to
> processing events/messages. In an effort to not create a science project
> out of some sort of top-down attack on this requirement, a simple
> middle-out approach with immediate results would be to extend the
> eventListener behavior that is prevalent in both browser and node.js
> scenarios.
>
> The case I am making first and foremost is that these recognizable
> patterns will be increasingly requisite (and not an after-thought, to be
> brought in via Underscore) in building web apps in the near term as web app
> complexity & use has increased dramatically with multiple cloud-scale
> offerings running in the SaaS space (think Netflix, LinkedIn, Facebook,
> Slack, etc) and more being built in various startups & emerging
> businesses. If the browser is to gain parity as an Application Platform
> allowing the development of web applications to rival native ones, then the
> ability to deal with volatile/durable messaging and events, storage and
> routing of work should be a core capability.
>
> *Broader implications:*
> If I may, let me add that I also think there is a growing confluence
> between the hybrid desktop app and browser-based SPAs (the Electron
> framework and its numerous successful projects like Atom, Slack, Visual
> Studio Code are great examples) and if the browser is to continue to evolve
> as a platform to encourage this trend (which is fabulous for the web
> community), then investments must be made to extend / normalize the browser
> standards in much the same way that the concept of a standardized
> Application Server helped standardize app architectures. This implies a
> future with registration of libraries/components (managed code), better
> local storage/caching options, improved integration with security contexts
> (per O/S), and likely much more. At least, I think it does :-).
>
>
> On Mon, Nov 27, 2017 at 6:48 PM, Jonathan Zuckerman  > wrote:
>
>> 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  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 

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

[Sylon Zero]

I think libraries having those functions emphasizes the point here, as that
validates the existence and need for those patterns which then raises the
requirement: should this be native to the browser?

I believe the answer is yes, given how much work has already been put into
standardizing the resource/computation model around the browser (web
workers, local storage, etc) which is architecturally, IMHO, a related
effort. Those capabilities come to life when there are smarter ways to
utilize and route work to them through built-in features related to
processing events/messages. In an effort to not create a science project
out of some sort of top-down attack on this requirement, a simple
middle-out approach with immediate results would be to extend the
eventListener behavior that is prevalent in both browser and node.js
scenarios.

The case I am making first and foremost is that these recognizable patterns
will be increasingly requisite (and not an after-thought, to be brought in
via Underscore) in building web apps in the near term as web app complexity
& use has increased dramatically with multiple cloud-scale offerings
running in the SaaS space (think Netflix, LinkedIn, Facebook, Slack, etc)
and more being built in various startups & emerging businesses. If the
browser is to gain parity as an Application Platform allowing the
development of web applications to rival native ones, then the ability to
deal with volatile/durable messaging and events, storage and routing of
work should be a core capability.

*Broader implications:*
If I may, let me add that I also think there is a growing confluence
between the hybrid desktop app and browser-based SPAs (the Electron
framework and its numerous successful projects like Atom, Slack, Visual
Studio Code are great examples) and if the browser is to continue to evolve
as a platform to encourage this trend (which is fabulous for the web
community), then investments must be made to extend / normalize the browser
standards in much the same way that the concept of a standardized
Application Server helped standardize app architectures. This implies a
future with registration of libraries/components (managed code), better
local storage/caching options, improved integration with security contexts
(per O/S), and likely much more. At least, I think it does :-).


On Mon, Nov 27, 2017 at 6:48 PM, Jonathan Zuckerman 
wrote:

> 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  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 

Re: [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  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
>