Hi,
Trying the move here the discussion happening at
https://bugzilla.mozilla.org/show_bug.cgi?id=686201 (recent discussion
starts comment 26)
Moving it here, because I believe it overlaps a lot with the ongoing
ES6/ES7 work bringing the event loop to ECMA262 (module loading,
Object.observe, etc.)
(In reply to dopazo.juan from comment #32)
Bringing some feedback from the discussion at the Chromium bug after
having some time to consider it. We need two APIs for scheduling stuff
that would serve different use cases:
1) A way to run a function after yielding back to the browser, like
setImmediate does. This would be useful for those cases where we
expect to do something after the browser had time to render, but as
soon as possible.
From what I understand, setTimeout 0 serves that use case and there is
no reason for setImmediate to be better at this job.
2) A way to run a function after the current microtask and before
yielding back to the browser, same as what Object.observe() does. This
is what we need for promises and other library features that depend on
some level of asynchronicity and deal with data. We want to work on
our data before the browser renders again.
I'm having a hard time understanding "before the browser renders again".
I'm afraid this is a asking for laggy UIs if there is the least bug. I
would rather recommend the following approach: play with "abstract" data
(regular objects/arrays, etc.) in tasks/microtasks and update UI (DOM,
Canvas, SVG, etc.) in requestAnimationFrame callbacks.
Kyle Simpson wrote:
Promises implementations necessarily have to insert a defer/delay
between each step of a sequence, even if all the steps of that
sequence are already fulfilled and would otherwise, if not wrapped in
promises, execute synchronously. The async "delay" between each step
is necessary to create a predictable execution order between sync and
async usage.
An implementation can keep track of the order in which messages arrived
to the queue and process them in order. No need to impose a delay, no?
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
