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

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 <j.zuckerman@gmail.com>
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 <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 Tuesday, 28 November 2017 05:02:45 UTC