JavaScript: requestAnimationFrame vs setTimeout

Before modern CSS transitions and canvas APIs, JavaScript developers built animations by placing DOM updates inside a setInterval or setTimeout loop, usually set to execute every 16 milliseconds (to simulate 60 frames per second).

Why is requestAnimationFrame significantly better for animations than setTimeout or setInterval?

This question separates candidates who understand basic JavaScript execution from those who deeply understand the browser rendering pipeline.

1. The Flaws of setTimeout for Animation

Using setTimeout(animate, 16) attempts to force the browser to execute a visual update every 16ms. However, this has massive drawbacks:

1. Ignorance of the Display Refresh Rate: Most monitors refresh at 60Hz (60 times a second), but modern gaming monitors might run at 120Hz or 144Hz. setTimeout fires blindly based on a fixed timer, completely decoupled from when the hardware screen is actually ready to draw the next frame. This leads to screen tearing and stuttering (jank).
2. Event Loop Inaccuracy: As discussed in event loop architecture, setTimeout(fn, 16) only guarantees a minimum delay of 16ms. If the main thread is busy with layout calculations or garbage collection, the callback might execute at 20ms or 30ms, ruining the animation's smoothness.
3. Battery and CPU Drain: If the user switches to a different browser tab, setTimeout continues firing endlessly in the background. Your code will recalculate DOM positions for an animation no one is looking at, draining the user's laptop battery.

2. Enter requestAnimationFrame (rAF)

The window.requestAnimationFrame() API tells the browser that you wish to perform an animation, and requests that the browser call a specific function right before the next repaint.

const box = document.getElementById('box');
let position = 0;
 
function animate() {
  position += 5;
  box.style.transform = `translateX(${position}px)`;
  
  if (position < 500) {
    // Recursively call rAF to schedule the next frame
    requestAnimationFrame(animate);
  }
}
 
// Start the animation
requestAnimationFrame(animate);

Why rAF is Superior

1. Perfect Synchronization: requestAnimationFrame aligns exactly with the device's refresh rate. If the monitor is 60Hz, it fires 60 times a second. If the monitor is 120Hz, it scales up beautifully.
2. V-Sync Integration: The browser optimizes concurrent animations together into a single reflow and repaint cycle, eliminating jitter.
3. Background Tab Throttling: The absolute biggest advantage of rAF is that it automatically pauses when the user switches to a different tab or minimizes the browser. This preserves CPU cycles, memory, and battery life dynamically.

3. Canceling an Animation

Similar to clearTimeout, requestAnimationFrame returns an integer ID that you can use to cancel the scheduled frame using cancelAnimationFrame().

const animationId = requestAnimationFrame(animate);
 
// User clicks a "Stop" button
cancelAnimationFrame(animationId);

Senior-Level Interview Answer

While setTimeout and setInterval can be used to execute visual updates on a fixed interval, they are fundamentally flawed for animations because they are pushed to the task queue completely ignorant of the browser's painting pipeline and the hardware's display refresh rate. This misalignment results in dropped frames and visual jank. requestAnimationFrame solves this by scheduling a callback to execute specifically in the macrotask queue right before the browser's next repaint cycle. This ensures updates are perfectly synchronized with the monitor's refresh rate (V-Sync). Furthermore, requestAnimationFrame includes vital performance optimizations, automatically pausing executions when the browser tab is inactive to heavily conserve CPU and battery life.

Common Interview Mistakes

❌ Misunderstanding where rAF sits in the Event Loop

Interviewers might ask if requestAnimationFrame has higher priority than Microtasks (Promises). It does not. Microtasks are exhausted completely before the Event Loop allows rendering. requestAnimationFrame is executed just before the render step, meaning it has higher priority than a standard setTimeout, but lower priority than Promise.resolve().

❌ Relying on rAF for strict timing (like a clock)

Because requestAnimationFrame pauses entirely when the tab is hidden, you should never use it as a chronological timer (e.g., counting down seconds for a crucial game timer). If the user switches tabs for 10 seconds, the animation loop freezes, and your timer will be permanently 10 seconds behind real-world time. Use Date.now() to calculate deltas if strict chronological tracking is required.