Comparison
TaskvsMicrotask
Task
your `setTimeout(fn, 0)` did not run immediately, it ran after the browser got a chance to paint.
One unit of work the browser picks off a queue and runs to completion: a script, a timer callback, an event handler, a network callback. Between tasks the browser is free to render, which is why breaking long work into separate tasks is what keeps a page responsive. Timers have a clamped minimum delay and background tabs throttle them heavily, so `setTimeout(fn, 0)` means 'soon', never 'now'.
Full entry →Microtask
the promise callback ran before the timeout you scheduled first, and before the browser painted anything.
A callback queued by a resolved promise, `queueMicrotask` or a mutation observer, which runs after the current task and before the browser gets a chance to render. The entire microtask queue is drained each time, including microtasks queued by microtasks, so a promise chain that keeps resolving can starve rendering indefinitely. That ordering — all microtasks, then render, then the next task — is the actual answer to why promise callbacks beat timers.
Full entry →