Event loop (macro vs microtasks)
Slap yourself if
You think microtasks are just 'faster callbacks' or believe the event loop runs one task per tick.
Why this exists
Because most frontend bugs blamed on 'async weirdness' are actually deterministic consequences of task queue prioritization that engineers never internalized.
Mental model
The event loop is not a loop over callbacks — it is a strict priority scheduler. Microtasks are a drain phase that must fully exhaust before the browser is allowed to breathe.
- A single macrotask is dequeued and executed to completion.
- Synchronous JS runs until the call stack is empty.
- The microtask queue is then drained completely — not one, all.
- Only after microtasks are empty can rendering, input, or the next macrotask occur.
- Recursive microtask scheduling that starves rendering.
- Assuming setTimeout(fn, 0) runs 'immediately' after a Promise.
- Mixing MutationObserver, Promise, and async/await without understanding ordering.
- Blaming React or the browser when the issue is queue starvation.
Macrotasks define execution slices; microtasks are a mandatory drain phase after each slice. Microtasks always run before the browser can render or handle input.
- Says microtasks run 'before everything'.
- Cannot explain why a resolved Promise blocks paint.
- Thinks requestAnimationFrame is a microtask.
- Uses 'tick' without defining what it means.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.