Comparison
TaskvsrequestAnimationFrame
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 →requestAnimationFrame
you moved the animation out of `setInterval` and it finally stopped stuttering at odd moments.
A callback scheduled to run immediately before the next paint, at the display's refresh rate, and suspended entirely in a background tab. It is the correct place for any visual update driven by script, because the work lands in the same frame as the paint that shows it. It gives you the frame budget too: whatever the callback does, layout and paint still have to fit in the same sixteen milliseconds.
Full entry →