2013/8/8 David Bruant <bruant.d at gmail.com>

>
>> 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.
>

That's precisely what we want to do and why we need a mechanism for
scheduling code to run in the next task/microtask.

Juan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130808/6cac4c23/attachment.html>

2013/8/8 David Bruant <bruant.d at gmail.com>

> 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.

That's precisely what we want to do and why we need a mechanism for
scheduling code to run in the next task/microtask.