JavaScript Event Loop and Concurrency: Understanding the Runtime

Master the JavaScript event loop with deep dives into call stacks, queues, microtasks, and macrotasks. Learn how async code executes and avoid common concurrency pitfalls.

Introduction
Understanding JavaScript’s Single-Threaded Nature
The JavaScript Runtime Architecture
How the Event Loop Works
Microtasks vs Macrotasks
Common Async Patterns and Their Execution Order
setTimeout, setInterval, and requestAnimationFrame
Promises and Async/Await in the Event Loop
Common Pitfalls and Gotchas
Debugging Async Code
Performance Considerations
Best Practices
Conclusion

Introduction

JavaScript’s event loop is one of the most fundamental concepts that every developer needs to understand, yet it’s often overlooked until you encounter mysterious bugs where code executes in an unexpected order. Have you ever wondered why setTimeout with a delay of 0 milliseconds doesn’t execute immediately? Or why Promises seem to execute before setTimeout callbacks even when both are scheduled at the same time? The answer lies in understanding how JavaScript’s event loop manages concurrency in a single-threaded environment.

JavaScript is single-threaded, meaning it can only execute one piece of code at a time. However, modern web applications need to handle multiple tasks simultaneously—responding to user interactions, fetching data from APIs, animating UI elements, and processing timers. The event loop is JavaScript’s elegant solution to this challenge, allowing asynchronous operations to run without blocking the main thread.

This comprehensive guide will take you deep into JavaScript’s runtime architecture, explaining how the event loop coordinates the execution of synchronous and asynchronous code. You’ll learn about the call stack, heap, callback queue, and microtask queue, and understand why certain code executes in a specific order. By the end, you’ll be able to predict execution order, debug async issues with confidence, and write more performant JavaScript code.

Understanding JavaScript’s Single-Threaded Nature

JavaScript runs on a single main thread, which means only one operation can execute at a time. This design choice simplifies the language and avoids the complexity of thread synchronization, but it also means that long-running operations can block the entire application.

Why Single-Threaded?

// ❌ This would block the entire application
function blockingOperation() {
  const start = Date.now();
  // Simulate heavy computation
  while (Date.now() - start < 5000) {
    // Blocking for 5 seconds
  }
  console.log('Done!');
}

blockingOperation();
console.log('This won't execute until blockingOperation completes');

If JavaScript were truly blocking, any heavy computation would freeze the browser. Instead, JavaScript uses an event loop to handle asynchronous operations, allowing the browser to remain responsive even while waiting for network requests, timers, or user interactions.

The Illusion of Concurrency

// ✅ Non-blocking with setTimeout
console.log("Start");

setTimeout(() => {
  console.log("Timer 1");
}, 0);

setTimeout(() => {
  console.log("Timer 2");
}, 0);

console.log("End");

// Output:
// Start
// End
// Timer 1
// Timer 2

Even though both setTimeout calls have a delay of 0 milliseconds, they don’t execute immediately. The event loop ensures that all synchronous code runs first, then processes the queued callbacks. This creates the illusion of concurrency while maintaining JavaScript’s single-threaded execution model.

The JavaScript Runtime Architecture

To understand the event loop, you need to know about the key components of JavaScript’s runtime environment. These components work together to manage code execution, memory, and asynchronous operations.

The Call Stack

The call stack is where JavaScript keeps track of function calls. When a function is invoked, it’s pushed onto the stack. When it returns, it’s popped off the stack.

function first() {
  console.log("First function");
  second();
}

function second() {
  console.log("Second function");
  third();
}

function third() {
  console.log("Third function");
}

first();

// Call stack visualization:
// [third]      <- top of stack
// [second]
// [first]
// [global]     <- bottom of stack

The Heap

The heap is where JavaScript stores objects and variables. It’s an unstructured memory region where memory allocation happens.

// Objects are stored in the heap
const user = {
  name: "John",
  age: 30,
  preferences: {
    theme: "dark",
    language: "en",
  },
};

// Arrays are also stored in the heap
const items = [1, 2, 3, 4, 5];

The Callback Queue (Macrotask Queue)

The callback queue (also called the macrotask queue or task queue) holds callbacks from asynchronous operations like setTimeout, setInterval, DOM events, and I/O operations.

// These callbacks go into the callback queue
setTimeout(() => {
  console.log("Macrotask 1");
}, 0);

setTimeout(() => {
  console.log("Macrotask 2");
}, 0);

The Microtask Queue

The microtask queue has higher priority than the callback queue. It holds callbacks from Promises, queueMicrotask(), and MutationObserver.

// These go into the microtask queue
Promise.resolve().then(() => {
  console.log("Microtask 1");
});

queueMicrotask(() => {
  console.log("Microtask 2");
});

How the Event Loop Works

The event loop is a continuous process that checks if the call stack is empty, and if so, moves tasks from the queues to the call stack for execution. Here’s the simplified algorithm:

Execute all synchronous code until the call stack is empty
Process all microtasks until the microtask queue is empty
Process one macrotask from the callback queue
Repeat from step 2

Visualizing the Event Loop

console.log("1: Start");

setTimeout(() => {
  console.log("2: setTimeout");
}, 0);

Promise.resolve().then(() => {
  console.log("3: Promise");
});

console.log("4: End");

// Execution order:
// 1: Start        <- Synchronous
// 4: End          <- Synchronous
// 3: Promise      <- Microtask (higher priority)
// 2: setTimeout   <- Macrotask (lower priority)

Step-by-Step Execution

Let’s trace through a more complex example:

console.log("Step 1");

setTimeout(() => {
  console.log("Step 2");
}, 0);

Promise.resolve().then(() => {
  console.log("Step 3");
  setTimeout(() => {
    console.log("Step 4");
  }, 0);
});

queueMicrotask(() => {
  console.log("Step 5");
});

console.log("Step 6");

// Execution order:
// Step 1  <- Synchronous
// Step 6  <- Synchronous
// Step 3  <- Microtask (first Promise)
// Step 5  <- Microtask (queueMicrotask)
// Step 2  <- Macrotask (first setTimeout)
// Step 4  <- Macrotask (setTimeout from Promise)

Execution flow:

All synchronous code runs (Step 1, Step 6)
Call stack is empty, so process microtasks
Promise.resolve().then() callback executes (Step 3)
Inside the Promise callback, setTimeout schedules Step 4 (goes to macrotask queue)
queueMicrotask callback executes (Step 5)
Microtask queue is empty, so process one macrotask (Step 2)
Microtask queue checked again (empty), process next macrotask (Step 4)

Microtasks vs Macrotasks

Understanding the difference between microtasks and macrotasks is crucial for predicting execution order in JavaScript.

What Are Microtasks?

Microtasks are high-priority tasks that execute immediately after the current synchronous code completes, before any macrotasks. They include:

Promise callbacks (.then(), .catch(), .finally())
queueMicrotask() callbacks
MutationObserver callbacks

console.log("Start");

// Macrotask
setTimeout(() => {
  console.log("Macrotask");
}, 0);

// Microtask
Promise.resolve().then(() => {
  console.log("Microtask");
});

console.log("End");

// Output:
// Start
// End
// Microtask    <- Executes first (higher priority)
// Macrotask    <- Executes second

What Are Macrotasks?

Macrotasks (also called tasks) are lower-priority tasks that execute after all microtasks are complete. They include:

setTimeout and setInterval callbacks
DOM event handlers (click, scroll, etc.)
I/O operations (file reading, network requests)
requestAnimationFrame callbacks

console.log("1");

setTimeout(() => console.log("2"), 0);
setTimeout(() => console.log("3"), 0);

Promise.resolve().then(() => {
  console.log("4");
  Promise.resolve().then(() => {
    console.log("5");
  });
});

console.log("6");

// Output:
// 1
// 6
// 4        <- All microtasks execute first
// 5        <- Even nested microtasks
// 2        <- Then macrotasks
// 3

Why This Matters

The microtask queue can starve the macrotask queue if microtasks keep adding more microtasks. This is why it’s important to understand execution order:

// ⚠️ This can block macrotasks indefinitely
function createMicrotask() {
  Promise.resolve().then(() => {
    console.log("Microtask");
    createMicrotask(); // Creates another microtask
  });
}

createMicrotask();

setTimeout(() => {
  console.log("This may never execute!");
}, 0);

Common Async Patterns and Their Execution Order

Let’s examine how different asynchronous patterns interact with the event loop.

Promises and the Microtask Queue

console.log("1");

new Promise((resolve) => {
  console.log("2"); // Executes synchronously
  resolve();
}).then(() => {
  console.log("3"); // Goes to microtask queue
});

console.log("4");

// Output:
// 1
// 2        <- Promise executor runs synchronously
// 4
// 3        <- .then() callback is a microtask

Async/Await Under the Hood

async/await is syntactic sugar over Promises, so it follows the same microtask rules:

async function asyncFunction() {
  console.log("1");
  await Promise.resolve();
  console.log("2"); // Everything after await is in a .then()
}

console.log("3");
asyncFunction();
console.log("4");

// Output:
// 3
// 1
// 4
// 2        <- Code after await executes as microtask

Mixing Promises and setTimeout

console.log("Start");

setTimeout(() => {
  console.log("setTimeout");
}, 0);

Promise.resolve()
  .then(() => {
    console.log("Promise 1");
    return Promise.resolve();
  })
  .then(() => {
    console.log("Promise 2");
  });

console.log("End");

// Output:
// Start
// End
// Promise 1    <- Microtasks execute first
// Promise 2    <- Chained microtasks
// setTimeout   <- Macrotask executes last

Nested Async Operations

console.log("1");

setTimeout(() => {
  console.log("2");
  Promise.resolve().then(() => {
    console.log("3");
  });
  console.log("4");
}, 0);

Promise.resolve().then(() => {
  console.log("5");
  setTimeout(() => {
    console.log("6");
  }, 0);
});

console.log("7");

// Output:
// 1
// 7
// 5        <- Microtask executes first
// 2        <- Macrotask executes
// 4        <- Synchronous code in macrotask
// 3        <- Microtask from within macrotask
// 6        <- Next macrotask

setTimeout, setInterval, and requestAnimationFrame

These timing functions are essential for scheduling code execution, but they behave differently in the event loop.

setTimeout

setTimeout schedules a callback to run after a minimum delay. The delay is not guaranteed—it’s the minimum time before the callback can execute.

console.log("Start");
const startTime = Date.now();

setTimeout(() => {
  const elapsed = Date.now() - startTime;
  console.log(`setTimeout executed after ${elapsed}ms`);
}, 100);

// Blocking operation
const endTime = Date.now() + 150;
while (Date.now() < endTime) {
  // Blocking for 150ms
}

console.log("End");

// Output:
// Start
// End
// setTimeout executed after ~150ms (not 100ms!)

setInterval

setInterval repeatedly schedules callbacks, but each callback is a separate macrotask:

let count = 0;

const intervalId = setInterval(() => {
  count++;
  console.log(`Interval ${count}`);

  if (count >= 3) {
    clearInterval(intervalId);
  }
}, 100);

// If the callback takes longer than 100ms, intervals may overlap

requestAnimationFrame

requestAnimationFrame is optimized for animations and runs before the next browser repaint. It’s not part of the standard event loop queues but behaves similarly to macrotasks:

function animate() {
  console.log("Animation frame");
  requestAnimationFrame(animate);
}

requestAnimationFrame(animate);

setTimeout(() => {
  console.log("setTimeout");
}, 0);

// requestAnimationFrame typically runs at ~60fps (every ~16ms)
// setTimeout runs when the event loop processes it

Zero-Delay setTimeout

A common pattern is using setTimeout(fn, 0) to defer execution until after the current call stack clears:

console.log("1");

setTimeout(() => {
  console.log("2");
}, 0);

console.log("3");

// Output:
// 1
// 3
// 2        <- Executes after synchronous code

This is useful for breaking up long-running operations:

// ✅ Breaking up heavy computation
function processLargeArray(items) {
  let index = 0;

  function processChunk() {
    const chunk = items.slice(index, index + 100);
    chunk.forEach(processItem);
    index += 100;

    if (index < items.length) {
      setTimeout(processChunk, 0); // Yield to event loop
    }
  }

  processChunk();
}

Promises and Async/Await in the Event Loop

Promises and async/await are built on top of the microtask queue, which gives them priority over macrotasks.

Promise Execution Flow

console.log("1");

new Promise((resolve) => {
  console.log("2"); // Executor runs synchronously
  resolve("resolved");
})
  .then((value) => {
    console.log("3", value); // Microtask
    return "chain";
  })
  .then((value) => {
    console.log("4", value); // Microtask
  });

console.log("5");

// Output:
// 1
// 2        <- Promise executor
// 5
// 3 resolved    <- First .then() microtask
// 4 chain       <- Second .then() microtask

Async Function Execution

async function fetchData() {
  console.log("1: Start fetch");
  const data = await fetch("/api/data"); // Pauses here
  console.log("2: Got data"); // Resumes as microtask
  return data;
}

console.log("3: Before call");
fetchData();
console.log("4: After call");

// Output:
// 3: Before call
// 1: Start fetch
// 4: After call
// 2: Got data    <- Executes when Promise resolves

Promise.all and Execution Order

console.log("Start");

Promise.all([
  Promise.resolve().then(() => console.log("Promise 1")),
  Promise.resolve().then(() => console.log("Promise 2")),
]).then(() => {
  console.log("All done");
});

setTimeout(() => {
  console.log("setTimeout");
}, 0);

console.log("End");

// Output:
// Start
// End
// Promise 1     <- Microtasks execute first
// Promise 2
// All done      <- .then() after Promise.all
// setTimeout    <- Macrotask executes last

Error Handling in the Event Loop

Promise.reject("Error")
  .catch((error) => {
    console.log("Caught:", error); // Microtask
    return "recovered";
  })
  .then((value) => {
    console.log("After catch:", value); // Microtask
  });

setTimeout(() => {
  console.log("setTimeout");
}, 0);

// Output:
// Caught: Error        <- Microtask
// After catch: recovered
// setTimeout           <- Macrotask

Common Pitfalls and Gotchas

Understanding the event loop helps you avoid these common mistakes.

Pitfall 1: Assuming setTimeout Executes Immediately

// ❌ Wrong assumption
console.log("Start");
setTimeout(() => {
  console.log("Delayed");
}, 0);
console.log("End");
// End executes before Delayed, even with 0ms delay

// ✅ Correct understanding
console.log("Start");
setTimeout(() => {
  console.log("Delayed"); // Executes after call stack clears
}, 0);
console.log("End");

Pitfall 2: Blocking the Event Loop

// ❌ Blocks the entire application
function heavyComputation() {
  const start = Date.now();
  while (Date.now() - start < 5000) {
    // Blocking for 5 seconds
  }
}

heavyComputation();
console.log('This won't execute for 5 seconds');

// ✅ Break up heavy operations
function heavyComputationAsync() {
  let processed = 0;
  const total = 1000000;

  function processChunk() {
    const chunkSize = 10000;
    for (let i = 0; i < chunkSize && processed < total; i++) {
      // Process item
      processed++;
    }

    if (processed < total) {
      setTimeout(processChunk, 0); // Yield to event loop
    } else {
      console.log("Done!");
    }
  }

  processChunk();
}

Pitfall 3: Microtask Queue Starvation

// ⚠️ This can prevent macrotasks from executing
function createInfiniteMicrotasks() {
  Promise.resolve().then(() => {
    console.log("Microtask");
    createInfiniteMicrotasks(); // Creates another microtask
  });
}

createInfiniteMicrotasks();

setTimeout(() => {
  console.log("This may never execute");
}, 0);

Pitfall 4: Incorrect Execution Order Assumptions

// ❌ Assuming Promises execute after setTimeout
setTimeout(() => console.log("1"), 0);
Promise.resolve().then(() => console.log("2"));

// Output: 2, 1 (not 1, 2!)

Pitfall 5: Race Conditions

// ⚠️ Race condition example
let value = 0;

Promise.resolve().then(() => {
  value = 1;
});

setTimeout(() => {
  console.log(value); // May log 0 or 1 depending on timing
}, 0);

value = 2;
console.log(value); // Always logs 2

Debugging Async Code

Debugging asynchronous code requires understanding the event loop and using the right tools.

Using console.log Strategically

console.log("1: Start");

setTimeout(() => {
  console.log("2: setTimeout");
}, 0);

Promise.resolve().then(() => {
  console.log("3: Promise");
  console.trace(); // Shows call stack
});

console.log("4: End");

Browser DevTools

Modern browsers provide excellent tools for debugging async code:

// Chrome DevTools async debugging
async function fetchUserData() {
  console.log("Fetching...");
  const response = await fetch("/api/user");
  const data = await response.json();
  console.log("Data:", data);
  return data;
}

// Set breakpoints in DevTools
// Use "Async" checkbox in call stack
// Step through Promise resolutions

Visualizing Execution Order

function logWithLabel(label) {
  console.log(`[${Date.now()}] ${label}`);
}

logWithLabel("Start");

setTimeout(() => {
  logWithLabel("setTimeout 1");
}, 0);

Promise.resolve().then(() => {
  logWithLabel("Promise 1");
});

setTimeout(() => {
  logWithLabel("setTimeout 2");
}, 0);

Promise.resolve().then(() => {
  logWithLabel("Promise 2");
});

logWithLabel("End");

Using Performance API

// Measure async operation timing
performance.mark("start");

setTimeout(() => {
  performance.mark("end");
  performance.measure("async-operation", "start", "end");
  const measure = performance.getEntriesByName("async-operation")[0];
  console.log(`Duration: ${measure.duration}ms`);
}, 100);

Performance Considerations

Understanding the event loop helps you write more performant code.

Minimizing Blocking Operations

// ❌ Blocks the event loop
function processLargeDataset(data) {
  return data.map(transform).filter(validate).reduce(aggregate);
}

// ✅ Break into chunks
async function processLargeDatasetAsync(data) {
  const chunkSize = 1000;
  const results = [];

  for (let i = 0; i < data.length; i += chunkSize) {
    const chunk = data.slice(i, i + chunkSize);
    const processed = chunk.map(transform).filter(validate);
    results.push(...processed);

    // Yield to event loop every chunk
    await new Promise((resolve) => setTimeout(resolve, 0));
  }

  return results.reduce(aggregate);
}

Optimizing Microtask Usage

// ❌ Too many microtasks
function processItems(items) {
  items.forEach((item) => {
    Promise.resolve().then(() => {
      processItem(item); // Creates many microtasks
    });
  });
}

// ✅ Batch microtasks
function processItemsOptimized(items) {
  Promise.resolve().then(() => {
    items.forEach(processItem); // Single microtask
  });
}

Debouncing and Throttling

// Debounce: Execute after delay, cancel if called again
function debounce(func, delay) {
  let timeoutId;
  return function (...args) {
    clearTimeout(timeoutId);
    timeoutId = setTimeout(() => func.apply(this, args), delay);
  };
}

// Throttle: Execute at most once per delay
function throttle(func, delay) {
  let lastCall = 0;
  return function (...args) {
    const now = Date.now();
    if (now - lastCall >= delay) {
      lastCall = now;
      func.apply(this, args);
    }
  };
}

Using requestIdleCallback

For non-critical work, use requestIdleCallback to execute during idle periods:

// Execute when browser is idle
requestIdleCallback(
  () => {
    // Non-critical work (analytics, logging, etc.)
    performBackgroundTask();
  },
  { timeout: 5000 },
);

Best Practices

Follow these best practices to write efficient, predictable async code.

✅ Use Promises for Async Operations

// ✅ Preferred: Promises
async function fetchData() {
  try {
    const response = await fetch("/api/data");
    return await response.json();
  } catch (error) {
    console.error("Error:", error);
    throw error;
  }
}

✅ Avoid Blocking the Event Loop

// ✅ Break up heavy operations
function processInChunks(items, chunkSize = 100) {
  let index = 0;

  function processNextChunk() {
    const chunk = items.slice(index, index + chunkSize);
    chunk.forEach(processItem);
    index += chunkSize;

    if (index < items.length) {
      setTimeout(processNextChunk, 0);
    }
  }

  processNextChunk();
}

✅ Understand Execution Order

// ✅ Predictable execution order
console.log("1");
Promise.resolve().then(() => console.log("2"));
setTimeout(() => console.log("3"), 0);
console.log("4");
// Output: 1, 4, 2, 3

✅ Use async/await for Readability

// ✅ Clear and readable
async function getUserData(userId) {
  const user = await fetchUser(userId);
  const posts = await fetchPosts(userId);
  const comments = await fetchComments(userId);
  return { user, posts, comments };
}

✅ Handle Errors Properly

// ✅ Comprehensive error handling
async function robustAsyncOperation() {
  try {
    const result = await riskyOperation();
    return result;
  } catch (error) {
    console.error("Operation failed:", error);
    // Fallback or recovery logic
    return defaultValue;
  }
}

❌ Avoid Infinite Microtask Loops

// ❌ Don't create infinite microtasks
function badPattern() {
  Promise.resolve().then(() => {
    badPattern(); // Creates infinite loop
  });
}

❌ Don’t Assume setTimeout Timing

// ❌ setTimeout delay is minimum, not guaranteed
setTimeout(() => {
  // This may execute later than expected
}, 100);

Conclusion

The JavaScript event loop is the mechanism that enables JavaScript to handle asynchronous operations in a single-threaded environment. Understanding how it works—from the call stack and heap to microtasks and macrotasks—is essential for writing efficient, predictable code.

Key takeaways from this guide:

JavaScript is single-threaded but uses an event loop to handle concurrency
Microtasks (Promises, queueMicrotask) execute before macrotasks (setTimeout, DOM events)
The event loop processes all microtasks before moving to the next macrotask
Blocking operations can freeze your application, so break up heavy computations
Understanding execution order helps you debug async issues and write better code

As you continue building JavaScript applications, keep the event loop in mind. Whether you’re working with Promises and async/await, handling React component lifecycle, or optimizing performance, understanding the event loop will help you write more efficient and maintainable code.

For more JavaScript fundamentals, check out our guide on understanding closures and comparing objects in JavaScript. To dive deeper into async patterns, explore the MDN documentation on Promises and the HTML5 Event Loop specification.

Table of Contents