Most sources say that there are two queues in the Event Loop: microtask queue and macrotask queue. But also some sources highlight the third queue (callbacks generated by requestAnimationFrame) and the fourth (callbacks generated by requestIdleCallback). How many queues are there actually, or is this just an implementation detail that may differ from browser to browser?

Most sources say that there are two queues in the Event Loop: microtask queue and macrotask queue. But also some sources highlight the third queue (callbacks generated by requestAnimationFrame) and the fourth (callbacks generated by requestIdleCallback). How many queues are there actually, or is this just an implementation detail that may differ from browser to browser?

• javascript
• browser
• event-loop

2 Answers 2

It is entirely an implementation detail, and even in a single browser, 2 pages might have a different number of queues, and even the same page can have different number of queues in its lifetime.

The specs state:

An event loop has one or more task queues. A task queue is a set of tasks.

So just for main tasks, which are visited at the beginning of the event-loop processing, we can have any number of queues, from 1 to many, the specs don't ask anything about it. What they do define are task sources, but many different task sources can come in the same task queue. And even the number of task-sources isn't defined, for instance, each MessagePort object has its own task-source, so potentially its own task-queue. Also, browsers are allowed to use multiple task-queues for a same task-source, as long as they act as if a single one existed and each queued task is executed in order. Firefox does this with the timer source before the page loaded so that timers queued in that period have less priority than other sources, and then they use another normal priority queue for the rest of the page's life.

And that was only about task queues...

Then there is indeed a microtask queue, which a different beast altogether. It will be called many times during the event loop processing, most of the time your code will meet it from the cleanup after running a script algorithm, which is ran every time your JS code execution ended, and, when the JS call stack is empty, will trigger a microtask checkpoint.

Regarding requestAnimationFrame, it's a bit different. Technically, it's not a queue, but a map. This allows us to remove animation frames later, and to queue new callbacks during a previous callback without calling it immediately. Now, the whole "animation" part of the event loop (actually called "update the rendering") is a bit more than just the animation frame callback. There are also all the callbacks for scroll, resize, CSS animations, IntersectionObserver, ResizeObserver, etc. This whole thing used to be part of every event-loop's iteration. This made things difficult for bloggers to correctly explain what it is, so it was often presented as being a queue on its own. Though it's not really. The specs have been rewritten so that it's now a task which has its own task source. But you don't queue there, the browser does it automatically.

And requestIdleCallback uses a list, though it could probably have been a map too. Its timing model is a bit similar to the update the rendering special task, in that it's also ultimately up to the browser to set when it will actually fire.

So maybe what all the sources were trying to pin point was that different tasks could have various priority. Though it should be noted that even task sources have a priority system. For instance UI events are often prioritized over network tasks. And we'll soon be able to queue our own callbacks in such prioritized tasks.

Your sources probably only list two queues for simplicity, but the event loop has at least four main ones:

• Microtask,
• Macrotask
• requestAnimationFrame,
• requestIdleCallback

However, there are also other queues depending on the environment, like those for Network events, UI interactions, Garbage Collection, and Web Workers.

The exact number of queues isn’t set in stone, and it varies based on the JavaScript engine (like V8, SpiderMonkey, or JavaScriptCore).