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.