The Event Loop, Precisely

• There is one call stack per page for your JavaScript. A function call pushes a frame; returning pops it. Nothing else runs while a frame is on that stack — the browser has no mechanism to preempt it (What the Main Thread Owns).
• The loop repeatedly does three things: run one task to completion, perform a microtask checkpoint, and possibly update the rendering. That is the entire model. Everything you know about setTimeout, promises, events and animation is a consequence of where a callback enters it.
• A task is one whole callback plus everything it synchronously calls. Tasks come from named task sources — timers, user interaction, DOM manipulation, networking, history traversal, postMessage — and each source keeps its own queue (Tasks: The Unit That Cannot Be Interrupted).
• A microtask checkpoint happens when the JavaScript execution context stack becomes empty. It drains the microtask queue to empty, including microtasks queued *during* the drain. Promise reactions and queueMicrotask land here (The Microtask Checkpoint).
• A rendering opportunity exists only between tasks, after that checkpoint, and only when the browser decides one is due. requestAnimationFrame callbacks run at that moment, before style and layout (The Rendering Opportunity).
• Asynchronous APIs never "wait". setTimeout, fetch and addEventListener all do the same shape of thing: hand a callback to a task source and return immediately. The waiting is done by the browser, on other threads, and the result arrives as a queued task (The Browser Is a Runtime).

1console.log("A");
2setTimeout(() => console.log("B"));
3Promise.resolve().then(() => console.log("C"));
4console.log("D");
5 
6// A  <- synchronous, runs now
7// D  <- synchronous, runs now
8// C  <- microtask: end of THIS task
9// B  <- task: the NEXT turn of the loop

TURN 1  --  task: "run the script"

  step  stack                          microtask queue   timer queue   output
  ----  -----------------------------  ----------------  ------------  ------
   1    log("A")                       -                 -             A
   2    setTimeout(cb_B)               -                 [cb_B]
   3    Promise.resolve().then(cb_C)   [cb_C]            [cb_B]
   4    log("D")                       [cb_C]            [cb_B]        D
   5    (script returns; stack empty)  [cb_C]            [cb_B]

  --> MICROTASK CHECKPOINT: drain to empty
   6    cb_C                           -                 [cb_B]        C
   7    (queue empty; checkpoint ends)

  --> rendering opportunity? maybe. If due, a frame is produced HERE.

TURN 2  --  task: the timer callback
   8    cb_B                           -                 -             B

• Learn to answer one question about any callback: which queue, and which turn? Every ordering argument in a code review resolves to that, and the answer is usually decidable from the API alone.
• Choose the queue for the meaning you want. A microtask means "before the browser can possibly paint" — good for keeping derived state consistent. A task means "after the browser has had a chance to paint" — good for letting the user see something first.
• Keep the unit of work small enough that the loop actually gets back to the top. Responsiveness is not a property of your function's speed; it is a property of how often the loop turns (Yielding and Scheduling).
• Treat requestAnimationFrame as the only correct place to write code that must be consistent with the frame about to be produced, and never as a general-purpose "run soon" (The Rendering Opportunity).
• When two callbacks must be ordered, order them explicitly — chain them, sequence them, or gate them on a flag. Relying on the relative ordering of two different task sources is relying on something the specification does not promise.