Microtasks, Macrotasks, and Rendering

The Classic Output Question

Every senior frontend interview has a version of this:

console.log('A');
setTimeout(() => console.log('B'), 0);
Promise.resolve().then(() => console.log('C'));
setTimeout(() => console.log('D'), 0);
Promise.resolve().then(() => console.log('E'));
console.log('F');

Output: A, F, C, E, B, D.

You probably knew that. But can you explain exactly why C and E group together, why they come before B, and what this has to do with rendering? That's the difference between memorizing patterns and understanding the machine.

The Mental Model

What Makes Something a Microtask vs. a Macrotask

This isn't arbitrary. The categorization follows a principle: microtasks are reactions to something that already happened in the current task. Macrotasks are new units of work from external sources.

Microtask Sources

Macrotask Sources

The Ordering Rules, Precisely

Here's the exact flow the browser follows after executing a task:

1. Execute ONE task from a task queue
2. DRAIN the microtask queue (all of them, including newly added ones)
3. If rendering opportunity:
   a. Run resize/scroll event handlers
   b. Run requestAnimationFrame callbacks
   c. Style → Layout → Paint → Composite
4. Go to step 1

The critical point is step 2: drain means execute every microtask, check if more were added, execute those, check again — until the queue is completely empty. Only then does the loop proceed.

Proof by Example

// Task: script execution
setTimeout(() => {
  // This is a NEW task (macrotask)
  console.log('timeout 1');
  Promise.resolve().then(() => console.log('micro inside timeout'));
}, 0);

Promise.resolve().then(() => {
  console.log('micro 1');
  Promise.resolve().then(() => console.log('micro 2'));
});

console.log('sync');

Final output: sync, micro 1, micro 2, timeout 1, micro inside timeout.

Notice: micro 2 runs before timeout 1 even though timeout 1 was registered first. Microtasks always win.

The Rendering Connection

This is where most tutorials stop. They explain microtask vs macrotask ordering but ignore the rendering pipeline. That's a mistake, because understanding when rendering happens is essential for building smooth UIs.

// Will the user see the red color?
element.style.backgroundColor = 'red';
element.style.backgroundColor = 'blue';

No. Both style changes happen within the same task. The browser only renders at the render step, which comes after the task and microtask checkpoint. By that time, the computed style is blue. The red frame never paints.

// Will the user see the red color?
element.style.backgroundColor = 'red';
requestAnimationFrame(() => {
  element.style.backgroundColor = 'blue';
});

Still no (in most cases). rAF runs in the same render step. The browser batches style changes and renders the final result. Both changes are processed before paint.

// WILL the user see the red color?
element.style.backgroundColor = 'red';
requestAnimationFrame(() => {
  requestAnimationFrame(() => {
    element.style.backgroundColor = 'blue';
  });
});

Yes. The first rAF sets up a callback for the next frame. So the browser paints red in frame 1, then in frame 2 the inner rAF runs and changes it to blue. The double-rAF trick is a well-known pattern for ensuring a visual change is painted before the next change.

Production Scenario: Microtask-based State Batching

React's state batching in React 18+ uses the microtask queue. When you call setState multiple times:

function handleClick() {
  setCount(1);    // doesn't trigger render yet
  setName('Bob'); // doesn't trigger render yet
  setAge(25);     // doesn't trigger render yet
  // React schedules ONE re-render as a microtask
}

React batches all state updates within the same event handler and schedules a single render as a microtask after the handler completes. This is why:

1. You don't see intermediate renders (count=1 but name still old)
2. The re-render happens before the next macrotask
3. The re-render happens before the browser paints

This wasn't always the case. Before React 18, batching only worked inside React event handlers. setTimeout callbacks, fetch .then() callbacks, and native event listeners would trigger synchronous re-renders for each setState. React 18's "automatic batching" extended this by using the microtask queue consistently.

The queueMicrotask API

queueMicrotask is the explicit way to schedule a microtask. It was added to give developers the same power that Promise.resolve().then() provides, without the overhead of creating a Promise:

// These are functionally identical:
Promise.resolve().then(() => doWork());
queueMicrotask(() => doWork());

// But queueMicrotask is:
// 1. More explicit in intent — "I want a microtask"
// 2. Slightly faster — no Promise allocation
// 3. Clearer in stack traces — no Promise wrapper

Use queueMicrotask when you need to defer work until after the current synchronous code completes but before any macrotask or rendering. Common use cases:

• Batching multiple synchronous operations into one async reaction
• Ensuring a callback runs after the current call stack unwinds
• Library internals that need microtask timing without Promise semantics

Common Mistakes

Challenge: Complex Ordering

Challenge: Mixed Micro and Macro

console.log('start');

setTimeout(() => {
  console.log('timeout 1');
  Promise.resolve().then(() => console.log('promise inside timeout'));
}, 0);

new Promise((resolve) => {
  console.log('promise executor');
  resolve();
}).then(() => {
  console.log('promise then');
  setTimeout(() => console.log('timeout inside promise'), 0);
});

console.log('end');

Key Rules