W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2013

Re: Queuing promise operations via microtasks rather than tasks

From: Igor Minar <iminar@google.com>
Date: Thu, 18 Jul 2013 09:42:27 -0700
Message-ID: <CAO9zZYMUgk-FwfDC8m_19gZ8+fD_0YZ57+dQBSucS24_ciobjA@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>
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

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

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


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.
Received on Thursday, 18 July 2013 16:43:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:03 UTC