David Bruant bruant.d at
Thu Aug 8 06:27:49 PDT 2013


Trying the move here the discussion happening at (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?


More information about the es-discuss mailing list