How does the JavaScript Event Loop handle microtasks versus macrotasks in modern browsers?

All answers to this question.

The order is always: Synchronous code first, then the Microtask queue (Promises, queueMicrotask), then the Macrotask queue (setTimeout, setInterval). Crucially, the browser tries to render between macrotasks, not microtasks. If you flood the microtask queue with a recursive promise chain, you will freeze the UI because the browser never gets a chance to paint. For smooth animations, requestAnimationFrame usually runs before the next paint, making it better for visual updates than setTimeout which just adds a task to the end of the macrotask queue.

   Answered 2025-03-20 by Barbara Wilson

Does your processing script involve heavy DOM manipulation, or is it mostly computational logic that could potentially be moved to a Web Worker to keep the main thread free?

   Answered 2025-04-05 by Steven Clark

• It's mostly heavy data parsing of JSON arrays. I hadn't considered Web Workers because I need to update the UI frequently. However, offloading the parsing logic and only sending the final result back to the main thread via postMessage sounds like it would solve my frame rate issues. I will look into how to serialize the data efficiently between threads.

     Commented 2025-04-18 by Gary Lawson

Always remember that Promise.resolve().then() will always execute before a setTimeout(..., 0). Understanding this priority is key to debugging race conditions in async code.

   Answered 2025-04-30 by Lisa Garcia

• Spot on, Lisa. I've seen so many bugs where people expect setTimeout to run immediately, but the microtask queue keeps it waiting longer than expected.

     Commented 2024-05-05 by Jessica Thompson