JebsetTimeout callbacks, user interaction events and scripts are macro tasks (or just tasks). When scheduled, they are added to a queue and are executed one by one (one per event loop cycle).
Promise and MutationObserver callbacks are micro tasks. They have their own queue which is executed until empty every time the JS call stack empties. This includes micro tasks that are scheduled during a micro task execution. You can also schedule a microtask with queueMicrotask.
requestAnimationFrame callbacks are queued into yet another queue, which is executed until empty upon every render (after the macro tasks bit and right before styling, layouting and painting). rAF that is scheduled during another rAF callback will execute on the next render.
This means that multiple macro tasks can occur in between two renders and multiple micro tasks as well as multiple rAF callbacks can occur in between two macro tasks. Each one of them might be possibly blocking for the main thread and thus hurt user experience.
Even if each one of these guys executes fast, when accumulated, they can create a significant delay between two renders. This is why Long Animation Frames (rather than Long Tasks) @nomsternom is working on are so important.
And now it’s riddle time! What will the following code print and when will the DOM change be actually painted to the screen?
Bonus question: what will change (if anything at all) if you resolve the promise in 30ms instead of 10ms?
And here are the options 😎.
Once the poll is concluded I Promise to dive in, there is a lot of interesting stuff to talk about here.
Once the poll is concluded I Promise to dive in, there is a lot of interesting stuff to talk about here.
T1,M1,rAF1,M2,M3,rAF2
M1,M3,T1,rAF1,rAF2,M2
T1,M1,M3,rAF1,M2,rAF2
T1,M1,M3,rAF1,rAF2,M2
Poll ended at .
To those who are curious about what's going on here and would like a hint about the bonus question I highly recommend (yes, again) watching this talk by @jaffathecake: https://www.youtube.com/watch?v=cCOL7MC4Pl0
