DOMContentLoaded 事件和任务队列

Question

I heard that there are three queues which have tasks in Event Loop Processing Model.

1. MacroTaskQueue: this queue have callback functions of setTimeout, setInterval..etc
2. MicroTaskQueue: this queue have callback functions of promise, mutationOberver..etc
3. AnimationFrameQueue: this queue have callback functions of requestAnimationFrame.

So, what i'm wondering is that

• Who fires DOMContentLoaded event?
• Where the callback function of DOMContentLoaded is queued? MacroTaskQueue or MicroTaskQueue?
• finally,

var a = 10;
console.log(a);

setTimeout(function b() { console.log('im b'); }, 1000);

in this code,

var a = 10;
console.log(a);

is this code also queued in MacroTaskQueue or MicroTaskQueue?

or only the b is queued in MacroTaskQueue after (min) 1000ms?

Im in black hole. Help me please:D

Answer 1

What you call the "MacroTaskQueue" is actually made of several task-queues , where tasks are being queued. (Note that the specs only use multiple task-sources , there could actually be a single task-queue). At the beginning of the event-loop processing , the browser will choose from which task queue it will pick the next "main" task to execute. It's important to understand that these tasks may very well not imply any JavaScript execution at all, JS is only a small part of what a browser does.

The microtask-queue will be visited and emptied several times during a single event-loop iteration. For instance every time that the JS call stack has been emptied (ie after almost every JS callback execution) and if it wasn't enough there are fixed "Perform a microtask checkpoint" points in the event-loop processing model .

While similar to a queue, the animation frame callbacks are actually stored in an ordered map, not in a queue per se, this allows to "queue" new callbacks from one of these callbacks without it being dequeued immediately after. More importantly, a lot of other callbacks are also executed at the same time , eg the scroll events, resize events, Web animation steps + events, ResizeObserver callbacks, etc. But this "update the rendering" step happens only once in a while, generally at the monitor refresh rate.

But, that's not saying much about DOMContentLoaded.

Who fires DOMContentLoaded event?

This event is fired as part of the Document parsing steps, in the "the end" section. The browser has to first queue a task on the DOM manipulation task-source. This task will then eventually get selected by the browser as part of the first step of the event-loop. And once this task's steps will be executed, the event will be fired and dispatched on the Document. That's only as part of this dispatch an event algorithm that the browser will invoke and inner-invoke until it calls our listener's callback.
Note that this Document parsing step is in itself quite interesting as a task since this is the most obvious place where you will have multiple microtask-checkpoints interleaved inside the "main" task (at each <script> for instance).

Where the callback function of DOMContentLoaded is queued?

The callback function is not queued, it is conceptually stored in the EventTarget's event listener list . In the facts, it's stored in memory, since here the EventTarget is a DOM object (Document), it's probably attached to this DOM object, though this is an implementation detail on which the specs have little to say as this is transparent to us web-devs.

MacroTaskQueue or MicroTaskQueue?

As I hope you now understand better, neither. Task queues and the microtask-queue only store tasks and microtasks, not callbacks. The callbacks are stored elsewhere, depending on what kind of callbacks they are (eg timers and events are stored in different "conceptual" places), and some task or microtask's steps will then call them.

is this code also queued in MacroTaskQueue or MicroTaskQueue?

That depends where this script has been parsed from. If it's inline in a classic <script> tag, then that would be the special parsing task we already talked about. If it's from a <script src="url.js"> , then it will be part of a task queued from fetch a classic script , but it can also be part of a microtask, eg if after an await in a module script, or you can even force it to be if you want:

 queueMicrotask(() => { console.log("in microtask"); eval(document.querySelector("[type=myscript]").textContent); console.log("still in microtask"); }); console.log("in parsing task");

 <script type="myscript"> var a = 10; console.log(a); setTimeout(function b() { console.log('im b'); }, 1000); </script>

And it is even theoretically possible by specs that a microtask becomes a "macro-"task, though no browser does implements this anymore apparently.
All this to say, while I personally find all this stuff fascinating, as a web-dev you shouldn't block yourself on it.