Logo Gerardo Perrucci - Full Stack Developer

JavaScript's Event Loop in Depth

June 18, 2025 • 20 min read • Gerardo Perrucci
JavaScript Event Loop Diagram

JavaScript is asynchronous by nature, thanks to the event loop. Understanding its mechanics is crucial for building non-blocking and responsive user interfaces.

 Decorative quote iconJavaScript, often described as a single-threaded language, presents an intriguing paradox: how does it manage to handle complex operations like network requests, user interactions, and timers without blocking the main thread and freezing the user interface? The answer lies in its sophisticated Event Loop mechanism.

For advanced engineers working with modern frameworks like React, a deep understanding of the event loop, its interaction with microtasks and macrotasks, and its pivotal role in browser rendering and DOM event handling is not merely academic—it's fundamental to building high-performance, responsive, and truly concurrent web applications.

The Core Components of the JavaScript Runtime

To truly grasp the event loop, we must first understand the environment in which JavaScript executes. The JavaScript engine itself (like V8 in Chrome or SpiderMonkey in Firefox) is lean, primarily containing the Call Stack and Heap. The magic of asynchronicity largely comes from the Web APIs provided by the browser and the queueing mechanisms that interact with the event loop.

1. The Call Stack

The Call Stack is a Last-In, First-Out (LIFO) stack that keeps track of the execution of your program. When a function is called, it's pushed onto the stack. When it returns, it's popped off. JavaScript executes one function at a time from top to bottom of the stack.

function thirdFunction() {
  console.log("Third function executed");
}

function secondFunction() {
  console.log("Second function executed");
  thirdFunction(); // Pushes thirdFunction onto the stack
}

function firstFunction() {
  console.log("First function executed");
  secondFunction(); // Pushes secondFunction onto the stack
}

firstFunction(); // Pushes firstFunction onto the stack
console.log("Global scope finished");

Execution Flow:

  1. firstFunction is pushed.
  2. console.log("First...") runs.
  3. secondFunction is pushed.
  4. console.log("Second...") runs.
  5. thirdFunction is pushed.
  6. console.log("Third...") runs.
  7. thirdFunction returns, popped from stack.
  8. secondFunction returns, popped from stack.
  9. firstFunction returns, popped from stack.
  10. console.log("Global...") runs.
  11. Global context finishes, popped from stack.

2. The Heap

The Heap is a large, unstructured region of memory where objects and variables are stored. Unlike the Call Stack, which manages the order of execution, the Heap is responsible for memory allocation for data structures.

3. Web APIs (Browser Environment)

These are not part of the JavaScript engine itself but are provided by the browser. They allow JavaScript to interact with the outside world and perform non-blocking operations. Examples include:

  • setTimeout() and setInterval(): For scheduling code execution after a delay.
  • DOM APIs: For interacting with the Document Object Model (e.g., addEventListener, querySelector).
  • fetch() and XMLHttpRequest: For making network requests.
  • location, localStorage, console: Other browser-provided functionalities.

When you call a Web API function (e.g., setTimeout(callback, delay)), the browser takes over, starts a timer, or initiates an I/O operation. Once the operation completes (e.g., the timer expires, data is fetched), the Web API places the associated callback function into a queue.

4. Callback Queue (Macrotask Queue / Task Queue)

This queue is where callbacks from Web APIs (like setTimeout, setInterval, I/O, UI rendering, etc.) are placed once their asynchronous operations are complete. These callbacks are considered macrotasks.

5. Microtask Queue (Job Queue)

Introduced with Promises in ES6, the Microtask Queue is a separate queue that holds microtasks. Microtasks have a higher priority than macrotasks. Callbacks from Promise.then(), Promise.catch(), Promise.finally(), and MutationObserver are typically placed here.

6. The Event Loop Itself

The Event Loop is the continuous process that monitors the Call Stack and the various queues. Its job is to move callbacks from the queues to the Call Stack for execution when the Call Stack is empty. This is the core mechanism that enables JavaScript's non-blocking, asynchronous behavior.

The Event Loop Algorithm: A Step-by-Step Breakdown

The event loop operates in a precise, iterative fashion. Think of it as a supervisor that constantly checks the state of the JavaScript runtime.

The event loop ensures that JavaScript remains non-blocking and responsive by carefully orchestrating the execution of synchronous and asynchronous code.

Here's the simplified algorithm for a single iteration (or "tick") of the event loop:

  1. Execute the Call Stack:
    • The event loop continuously checks if the Call Stack is empty.
    • If it's not empty, it executes all currently stacked functions synchronously until the Call Stack becomes empty. This is where all the initial synchronous code runs.
  2. Process Microtasks:
    • Once the Call Stack is empty, the event loop checks the Microtask Queue.
    • It then moves all callbacks from the Microtask Queue to the Call Stack and executes them, one by one, until the Microtask Queue is completely empty. This is why microtasks are considered "high priority"—they effectively "cut in line" before the next macrotask can execute.
  3. Browser Rendering (if applicable):
    • After all microtasks have been processed and the Call Stack is empty again, the browser may choose to perform a rendering update if one is pending and enough time has passed (typically aiming for 60 frames per second, or roughly every 16.6ms). This includes layout, paint, and composite phases.
  4. Process One Macrotask:
    • Finally, the event loop takes one callback from the Macrotask Queue and pushes it onto the Call Stack for execution.
    • After this single macrotask finishes, the Call Stack becomes empty again, and the entire cycle (steps 1-4) repeats.

This "one macrotask per iteration" rule is crucial. It ensures that the browser doesn't get stuck processing a long chain of setTimeout callbacks, allowing for rendering updates and user input to be processed intermittently.

Microtasks vs. Macrotasks: Prioritization and Implications

The distinction between microtasks and macrotasks is paramount for understanding asynchronous execution order and ensuring UI responsiveness.

What are Macrotasks?

Macrotasks (also known as tasks) represent discrete, larger units of work. They are scheduled to run after the current execution context and all pending microtasks have completed. If a macrotask runs for too long, it can block the main thread, leading to a "janky" or unresponsive UI.

Common Macrotask Sources:

  • setTimeout() callbacks
  • setInterval() callbacks
  • UI events (e.g., click, mousemove, keydown)
  • I/O operations (e.g., XMLHttpRequest.onload, fetch's internal handling of network responses before Promise resolution)
  • requestAnimationFrame (though its scheduling is closely tied to the browser's rendering cycle)

What are Microtasks?

Microtasks (also known as jobs) are smaller, higher-priority units of work. They are executed immediately after the current script finishes, before the next macrotask is picked up from the queue. This makes them ideal for tasks that need to be completed quickly after an asynchronous operation, like resolving Promises, to avoid visual glitches or inconsistent states.

Common Microtask Sources:

  • Promise.then(), Promise.catch(), Promise.finally() callbacks
  • async/await (syntactic sugar built on Promises, so await expressions generate microtasks)
  • MutationObserver callbacks (for observing changes to the DOM)
  • queueMicrotask() (a dedicated API for scheduling microtasks directly)

Comparative Table: Microtasks vs. Macrotasks

FeatureMicrotasksMacrotasks
PriorityHigh (executed before next macrotask)Low (executed one per event loop iteration)
ExecutionAll pending microtasks run consecutivelyOnly one pending macrotask runs per iteration
SourcesPromise.then(), async/await, MutationObserver, queueMicrotask()setTimeout(), setInterval(), UI Events, I/O, requestAnimationFrame
Impact on UICan delay next render if too many/longCan cause jank if a single task is too long
Use CaseChaining asynchronous operations, DOM observation, immediate updates after Promise resolutionDeferring tasks, handling user input, periodic updates

Practical Example (TypeScript): Execution Order

Let's illustrate the precise execution order in a browser environment.

console.log("1. Script start");

setTimeout(() => {
  console.log("5. setTimeout callback (Macrotask)");
}, 0); // Scheduled as a macrotask

Promise.resolve().then(() => {
  console.log("3. Promise.then callback (Microtask 1)");
  Promise.resolve().then(() => {
    console.log("4. Inner Promise.then callback (Microtask 2)");
  });
});

console.log("2. Script end");

// Simulate a click event
document.addEventListener('click', () => {
  console.log("6. Click event callback (Macrotask)");
  Promise.resolve().then(() => {
    console.log("7. Click event Promise (Microtask 3)");
  });
});

// To trigger the click event, you would manually click somewhere on the page
// or programmatically dispatch an event:
// const button = document.createElement('button');
// document.body.appendChild(button);
// button.click(); // This would trigger the click event listener

Expected Output (assuming no manual click initially):

1. Script start
2. Script end
3. Promise.then callback (Microtask 1)
4. Inner Promise.then callback (Microtask 2)
5. setTimeout callback (Macrotask)

Explanation:

  1. console.log("1. Script start") runs immediately (synchronous).
  2. setTimeout is encountered. Its callback is sent to the Web APIs and scheduled to be moved to the Macrotask Queue after the timer expires (even if 0ms, it's still asynchronous).
  3. Promise.resolve().then() is encountered. Its callback is sent to the Microtask Queue.
  4. console.log("2. Script end") runs immediately (synchronous).
  5. The Call Stack is now empty. The Event Loop checks the Microtask Queue.
  6. "3. Promise.then callback (Microtask 1)" is moved to the Call Stack and executed. Inside it, another Promise.resolve().then() schedules "4. Inner Promise.then callback (Microtask 2)" to the Microtask Queue.
  7. The Call Stack becomes empty again. The Event Loop re-checks the Microtask Queue and finds the newly added microtask.
  8. "4. Inner Promise.then callback (Microtask 2)" is moved to the Call Stack and executed.
  9. The Call Stack is empty, and the Microtask Queue is now empty.
  10. The Event Loop checks the Macrotask Queue and finds the setTimeout callback.
  11. "5. setTimeout callback (Macrotask)" is moved to the Call Stack and executed.

If you click after the initial output:

6. Click event callback (Macrotask)
7. Click event Promise (Microtask 3)

Explanation of Click:

  1. The click event occurs. The browser places the associated callback into the Macrotask Queue.
  2. In a subsequent event loop iteration, after any pending microtasks from the previous iteration, the click callback is picked up as a new macrotask.
  3. "6. Click event callback (Macrotask)" executes.
  4. Inside the click callback, Promise.resolve().then() schedules "7. Click event Promise (Microtask 3)" into the Microtask Queue.
  5. After "6." finishes, the Call Stack is empty. The event loop immediately processes the newly added microtask "7. Click event Promise (Microtask 3)".

DOM Events and the Event Loop: Capturing User Interaction

DOM events (like click, mouseover, submit, input) are a primary source of user interaction in web applications. Their execution also relies heavily on the event loop.

When you use element.addEventListener('event', callbackFunction), you are registering that callbackFunction with the browser's Web APIs. The browser monitors for the specified event (e.g., a mouse click on an element).

When the event occurs:

  1. The browser's internal event dispatching mechanism identifies the event.
  2. It places the corresponding event listener callback function into the Macrotask Queue.
  3. In a subsequent tick of the event loop (when the Call Stack is empty and all microtasks have been processed), this macrotask is picked up and executed, leading to your callbackFunction running.

This Macrotask-based handling of DOM events ensures that user interactions remain responsive. Even if your application is busy processing complex data, a click event will eventually be handled because the event loop will periodically check the Macrotask Queue between rendering updates or other long-running tasks.

Browser Rendering and the Event Loop: The Dance of Frames

The seamless animation and fluidity of modern web applications depend on the browser's ability to render new frames at a high rate (typically 60 frames per second, meaning a new frame every 16.6 milliseconds). The event loop plays a crucial role here, as rendering often occurs between macrotasks.

The Rendering Pipeline: When the browser needs to render (e.g., after a DOM change), it typically goes through these phases:

  1. Style: Calculates the styles for all elements.
  2. Layout: Determines the size and position of all elements on the page.
  3. Paint: Fills in the pixels for elements (text, colors, images, borders).
  4. Compositing: Combines layers to form the final image on the screen.

When does rendering happen? Crucially, rendering happens after the Call Stack is empty and all pending microtasks have been executed, but before the next macrotask is pulled from the queue. If your JavaScript code blocks the main thread with a long-running synchronous task or an excessively large number of microtasks, it will delay the next rendering update, leading to a visible "jank" or unresponsive UI.

requestAnimationFrame (rAF): requestAnimationFrame is a special Web API designed for animations. Its callback is scheduled to run just before the browser's next repaint. This makes it ideal for animation as it synchronizes with the browser's rendering cycle, ensuring smooth, non-janky animations. While often categorized loosely with macrotasks or as its own unique queue, its execution timing is tightly coupled with the rendering opportunity.

React and the Event Loop: The Reconciliation Tango

React's core reconciliation process, where it updates the DOM based on changes in component state, is deeply intertwined with the event loop. React's goal is to keep the UI synchronized with your application state efficiently, and its latest features (especially in React 18 with Concurrent Mode) leverage the event loop's scheduling capabilities to achieve this.

React's Rendering Process Simplified:

  1. Render Phase (Reconciliation):

    • This phase involves calling component functions, executing render methods, and calculating the differences (diffing) between the new Virtual DOM and the old Virtual DOM.
    • Crucially, this phase is interruptible. In React 18's Concurrent Mode, React can pause this work, yield control back to the browser (allowing it to render or handle user input), and then resume later. This is where React's scheduler comes into play.

  2. Commit Phase:

    • Once the diffing is complete, React applies the necessary changes to the actual browser DOM.
    • This phase is synchronous and uninterruptible. React needs to update the DOM immediately to avoid visual inconsistencies. Lifecycle methods like componentDidMount, componentDidUpdate, and useLayoutEffect fire during this phase.

How setState and useState Schedule Updates:

When you call setState (in class components) or the setter function from useState (in functional components), React doesn't necessarily re-render immediately. Instead, it schedules an update. React's internal scheduler then prioritizes and batches these updates.

Historically (before React 18's Concurrent Mode), React updates were largely synchronous or batched into a single macrotask. This could lead to a "long task" blocking the main thread if many updates occurred at once, resulting in jank.

React 18 Concurrent Mode: Leveraging the Event Loop for Responsiveness

React 18 introduces the concept of Concurrency, allowing React to work on multiple tasks at once and prioritize them. This is not true parallelism (JavaScript is still single-threaded), but rather intelligent scheduling that gives the illusion of concurrency. It achieves this by working with the browser's event loop.

Key mechanisms:

  • Scheduler: React 18 has its own internal scheduler that prioritizes updates. It can mark updates as urgent (e.g., direct user input) or non-urgent (e.g., background data fetching).

  • Yielding Control: During the interruptible Render Phase, React can "yield" control back to the browser. This means it can stop its rendering work, allow the browser to process high-priority tasks (like user input, requestAnimationFrame for animations, or painting), and then resume its work later. This yielding happens between chunks of work, often driven by requestIdleCallback (conceptually, though React's scheduler uses its own internal logic which is more sophisticated than requestIdleCallback alone) or by setting internal timers.

  • startTransition and useDeferredValue: These new APIs allow developers to explicitly mark updates as "transitions" – non-urgent updates that can be interrupted by more urgent ones.

    • startTransition: Wraps an update to mark it as a transition. React will try to render the transition, but if a more urgent update comes in (like a direct user input), it will discard the partial transition render and prioritize the urgent update.
    • useDeferredValue: A hook that defers updating a value, allowing the UI to remain responsive even if the underlying value is computationally expensive to render. It basically creates a "lagging" version of the value that updates at a lower priority.

This intelligent scheduling is achieved by strategically breaking down the Render Phase into smaller units of work. After completing a unit, React checks if the browser needs to perform urgent tasks. If so, React yields control, allowing the browser to process its queues (microtasks, then one macrotask, then potentially rendering). When the browser is ready, React resumes its interrupted rendering work. This prevents React's rendering from monopolizing the main thread.

// React TypeScript Example: Demonstrating Concurrent Updates
import React, { useState, useTransition, useDeferredValue } from 'react';
import { createRoot } from 'react-dom/client';

function App() {
  const [inputValue, setInputValue] = useState('');
  const [listQuery, setListQuery] = useState('');
  const [isPending, startTransition] = useTransition(); // Hook for transitions
  const deferredListQuery = useDeferredValue(listQuery); // Hook for deferred values

  const handleInputChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const value = e.target.value;
    setInputValue(value); // Urgent update: immediate feedback for input

    // Non-urgent update: deferred search
    startTransition(() => {
      setListQuery(value);
    });
  };

  // Simulate a heavy list rendering based on the deferred value
  const generateList = (query: string) => {
    console.log(`Generating list for: ${query}`); // See when this actually runs
    const items = [];
    for (let i = 0; i < 20000; i++) { // Large number of items to simulate heavy work
      items.push(<li key={i}>{`${query} - Item ${i}`}</li>);
    }
    return items;
  };

  return (
    <div>
      <h1>React Concurrent Features & Event Loop</h1>
      <input
        type="text"
        value={inputValue}
        onChange={handleInputChange}
        placeholder="Type to search..."
      />
      {isPending && <p style={{ color: 'blue' }}>Updating list (pending)...</p>}
      <hr />
      <h2>Search Results:</h2>
      {/* Use deferredListQuery to render the list, allowing input to remain responsive */}
      <ul style={{ opacity: isPending ? 0.5 : 1 }}>
        {generateList(deferredListQuery)}
      </ul>
    </div>
  );
}

const container = document.getElementById('root');
const root = createRoot(container!); // Create a concurrent root
root.render(<App />);

// In your index.html:
// <div id="root"></div>

Explanation:

  1. setInputValue(value): This is an urgent update. React processes this synchronously in the input handler. The input field updates instantly, providing immediate feedback.
  2. startTransition(() => { setListQuery(value); }): This wraps the setListQuery call, marking it as a non-urgent transition.
    • When you type rapidly, setListQuery is called repeatedly. Because it's inside startTransition, React's scheduler knows it can be interrupted.
    • The generateList function, which is computationally expensive due to 20,000 iterations, will be called with deferredListQuery.
    • useDeferredValue(listQuery): This hook provides a "stale" version of listQuery while the listQuery (triggered by the transition) is being updated. This means generateList will initially receive the previous listQuery value, allowing the current UI to remain responsive. Only after the startTransition finishes its work (or yields control and resumes) will deferredListQuery update, triggering the heavy rendering.
    • If a new urgent update (like another character typed in the input) comes in while the transition is pending, React will discard the in-progress transition rendering and prioritize the urgent input update. The isPending state indicates when a transition is underway.

This example clearly shows how React, by understanding the event loop and strategically using its scheduler, can prevent long rendering tasks from blocking user input, leading to a much smoother user experience, especially on slower devices or with complex UIs.

Advanced Topics and Pitfalls

process.nextTick() (Node.js Specific)

In Node.js, process.nextTick() is a unique microtask that runs before any Promises in the microtask queue and before the event loop gets to checking I/O or setTimeout callbacks. It's often used for situations where you need to defer an action but ensure it runs as quickly as possible within the same event loop iteration. It is not available in browsers.

setImmediate() (Node.js Specific)

Also Node.js specific, setImmediate() schedules a callback to execute immediately after the current event loop phase completes. It runs after any setTimeout(..., 0) callbacks but before the next event loop iteration that would process setTimeouts. It's designed for scenarios where you want to yield control but still have your callback run within the same "check" phase. It is not available in browsers.

requestIdleCallback() vs. requestAnimationFrame()

  • requestAnimationFrame (rAF): Designed for animations and visual updates. Its callback runs just before the browser's next repaint, ensuring animations are smooth and synchronized with the display refresh rate. It's a high-priority task.
  • requestIdleCallback (rIC): Designed for non-essential, background tasks that can run when the browser is idle. Its callback runs only if the browser has spare time at the end of an event loop iteration and before the next frame is due. It receives a deadline argument, allowing you to check how much time is left. If the deadline expires, the task is deferred to the next idle period. It's a low-priority task, perfect for analytics or background computations that shouldn't impact user experience.

Common Mistakes: Blocking the Main Thread

The most critical pitfall is writing long-running synchronous code that blocks the Call Stack. This prevents the event loop from operating, freezing the UI, delaying rendering, and making the application unresponsive.

// Anti-pattern: Blocking the main thread
function calculateHeavy() {
  let sum = 0;
  for (let i = 0; i < 1000000000; i++) { // A billion iterations!
    sum += i;
  }
  console.log("Heavy calculation done:", sum);
}

console.log("Start");
calculateHeavy(); // This will block the UI until it finishes
console.log("End");

When to Use Web Workers

For truly CPU-intensive computations that cannot be broken down into smaller, asynchronous chunks, Web Workers are the solution. Web Workers run scripts in a separate thread, completely isolated from the main thread. This means they cannot directly access the DOM but communicate with the main thread via message passing. This offloads heavy computation, keeping your UI responsive.

Conclusion: Mastering Asynchronicity for Superior UX

The JavaScript event loop is far more than a simple queue manager; it's the sophisticated orchestrator that allows a single-threaded language to manage complex asynchronous operations, handle user interactions, and render dynamic user interfaces seamlessly. For advanced engineers, a deep understanding of the Call Stack, Web APIs, Macrotask Queue, and Microtask Queue, alongside their precise interaction within the event loop's iterative algorithm, is non-negotiable.

React's evolution, particularly with Concurrent Mode in React 18, beautifully exemplifies how a framework can leverage and cooperate with the browser's event loop to achieve unprecedented levels of UI responsiveness and perceived concurrency. By mastering these underlying mechanics, you gain the power to diagnose performance bottlenecks, optimize rendering, and ultimately build web applications that deliver a fluid, delightful user experience. The unseen orchestrator, once demystified, becomes a powerful ally in the pursuit of exceptional web development.

References and Resources