Week 7: Callbacks, the Event Loop & Promises

1. The Call Stack & Why Callbacks Exist

JavaScript runs on a single thread, tracked by a structure called the call stack — every time a function is called, it's pushed onto the stack; when it returns, it's popped off. Only one thing can run at a time:

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

first();
// Call order:   first -> second -> third
// Stack builds: [first] -> [first, second] -> [first, second, third]
// Log order:    "third", "second", "first" -- each pops off before the next log runs

Because there's only one stack, a slow operation — like waiting several seconds for a network response — would freeze the entire page if it blocked the stack the whole time. JavaScript's answer is to hand slow work off to the browser (or Node) itself, and give it a callback: a function to run once that work finishes, instead of waiting for it inline.

console.log("1: start");

setTimeout(() => {
  console.log("2: this runs later, after the timer");
}, 1000);

console.log("3: this runs immediately");

// Logged order: "1: start", "3: this runs immediately", "2: this runs later..."

setTimeout doesn't block anything — it registers the callback and returns immediately, letting "3: this runs immediately" log before the timer callback ever runs. This is the foundation everything else this week builds on: JavaScript stays responsive by never blocking the stack on slow work, and running the "what happens after" logic later, as a callback.

2. Callback Hell

The trouble starts once one async step needs to happen after another — nesting callbacks inside callbacks quickly becomes hard to read and harder to maintain:

getUser(userId, (user) => {
  getOrders(user.id, (orders) => {
    getOrderDetails(orders[0].id, (details) => {
      getShippingStatus(details.id, (status) => {
        console.log(status); // four levels deep, and still growing rightward
      });
    });
  });
});

Each step depends on the result of the one before it, so each new step nests one level deeper — the code drifts rightward across the page ("the pyramid of doom"), and error handling has to be repeated at every single level individually. This specific pain is exactly what Promises were designed to solve, which is why they exist as a language feature at all rather than just a library convention.

3. The Event Loop & Task Queue

When an async operation (like a timer) finishes, its callback doesn't run immediately — it's placed in a task queue, and the event loop is the mechanism that continuously checks one thing: is the call stack empty? If so, take the next callback off the queue and run it.

console.log("A");

setTimeout(() => console.log("B"), 0); // 0ms delay -- still goes through the queue

console.log("C");

// Logged order: A, C, B -- NOT A, B, C

Even with a 0ms delay, "B" logs last. The timer callback can only run once the call stack is completely empty — and the stack isn't empty until console.log("C") and the rest of the currently-running code have finished. This is the core mental model for the rest of async JavaScript: the main script always finishes running first; queued callbacks only get their turn once the stack clears.

4. Promises: Creating & Consuming

A Promise is an object representing a value that isn't available yet, but will be — eventually resolved (success) or rejected (failure). It replaces the callback-passing pattern from Section 1 and 2 with something that can be returned and chained like a normal value:

function fetchUser(id) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (id > 0) {
        resolve({ id, name: "Priya" }); // success: call resolve with the value
      } else {
        reject(new Error("Invalid user ID")); // failure: call reject with an error
      }
    }, 500);
  });
}

fetchUser(1)
  .then((user) => console.log("Got:", user)) // runs if the Promise resolves
  .catch((err) => console.log("Failed:", err.message)); // runs if it rejects

A Promise starts pending, then settles exactly once — either fulfilled (whatever was passed to resolve) or rejected (whatever was passed to reject), and never changes again after that. .then() registers a callback for the success case; .catch() registers one for the failure case — both are just structured versions of the same "callback for later" idea from Section 1, wrapped in an object that can be passed around and chained.

5. Chaining Promises

.then() itself returns a new Promise, which is what makes chaining possible — and it's the direct fix for the callback-hell pyramid from Section 2:

getUser(userId)
  .then((user) => getOrders(user.id))
  .then((orders) => getOrderDetails(orders[0].id))
  .then((details) => getShippingStatus(details.id))
  .then((status) => console.log(status))
  .catch((err) => console.log("Something failed:", err.message)); // catches ANY step's failure

Each .then() receives the value the previous one resolved with, and whatever it returns becomes the value the next .then() receives — if a step returns another Promise (like getOrders(...) above), the chain automatically waits for that Promise to settle before continuing. The structure is now flat instead of nested, and a single .catch() at the end handles a rejection from any step in the chain, instead of repeating error handling at every level.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.