Re: Queuing promise operations via microtasks rather than tasks

Thanks for the pointer Domenic.

Yehuda's reasoning is exactly my use case as well. However my previous
example demonstrates that the issue exists even without a fancy
DOM-operation-coalescing layer that js frameworks like Angular or Ember
offer.

It's a realization that we discovered in Angular as soon as we started
adding promise support to the framework and something that has been
validated over and over for the past ~2 years of seeing it implemented in
practice.

It would be great if we avoided this pitfall in the standard.

/i


On Thu, Jul 18, 2013 at 7:13 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

>  Yeah, I think all involved agree that microtasks is how it should be
> handled. But there's so much confusion about how to spec the event loop and
> the different task queues, nobody has actually gotten around to updating
> the spec in that regard. We should probably add a note saying "this will
> probably use microtasks" for now.
>
> The best summary of the desired situation that I've seen has come from
> Yehuda, at https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296#c16
>
>
>  ------------------------------
> *From:* Igor Minar [iminar@google.com]
> *Sent:* Thursday, July 18, 2013 02:52
> *To:* www-dom@w3.org
> *Subject:* Queuing promise operations via microtasks rather than tasks
>
>   The dom promises spec specifies that operations like fulfillment or
> rejection should be handled by queueing a task<http://dom.spec.whatwg.org/#promises-model>to perform this operation.
>
>  Using the task queue however means that if several promises are queued
> to be fulfilled at the same time, the browser will be forced to re-render
> the dom after each promise fulfillment (supposing that each of the
> resolution will result in dom operation that needs to be reflected in the
> UI).. See point 4.3 in the event loop processing model<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-4>
> .
>
>  This kind of processing model will result in unnecessary flicker, which
> will impact the user experience.
>
>  I think that all of the flicker could be avoided and the performance of
> the apps could be improved if the microtasks similar to those used by the
> mutation observers<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#perform-a-microtask-checkpoint> were
> used instead of tasks.
>
>  Is this something that could be considered?
>
>
>
>
>  A concrete example:
>
>  given a function fetchJSON similar to the one used in promise intro and
> a a simplistic function updateDOM:
>
>  function updateDOM(location) {
>    return function(data) {
>     document.getElementById(location).textContent = data
>   };
> }
>
>  ['widget1', 'widget2', 'widget3'].forEach(function(widgetName) {
>   fetchJSON('/data/' + widgetName).then(updateDOM(widgetName));
> });
>
>  Everything would work as expected... until, we modified the fetchJSON
> function to fulfill its promise from an in-memory cache that has been
> primed already for all 3 of our widgets. So unlike before all three
> fetchJSON promises are now being scheduled to be fulfilled from a single
> task, but the fulfillment will result in three new tasks each of them
> performing the dom update and causing new re-rendering.
>
>  It would be way more efficient and the user experience would be improved
> significantly if the fulfillment happened in a single new tasks (preserving
> the async resolution) and only once all of the dom manipulation is done,
> the browser would render the UI at the final state just once, skipping all
> the intermediate updates.
>