3.6 — The call stack (first look)

In 3.3 you saw the engine jump into a function and jump back. But here’s the question that makes everything tick: when makeTea() calls boilWater(), and boilWater finishes… how does the engine know exactly where to go back to? Not roughly — exactly: the right function, the right line, with all its variables intact.

The answer is a beautifully simple machine called the call stack: a tower of paper cards. Every call places a new card on top; every finished call removes the top card — and the card underneath still says exactly where its function was paused. Watch the tower breathe.

watch it happen

function makeTea() {
  boilWater();
  console.log("tea is ready");
}

function boilWater() {
  console.log("water is hot");
}

makeTea();

The engine reads both definitions and — say it with me — runs nothing. Two machines stored, stack empty. Execution starts at line 10, the only line that actually DOES something.

console(nothing logged yet)

under the hood

The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”

The real vocabulary: each card is a stack frame — it holds the function’s parameters, its local variables, and the return address (the exact spot to resume). The stack is LIFO — last in, first out — like a stack of plates: you can only add or remove at the top.

One frame per call, not per function: call the same function twice and it gets two separate frames (lesson 3.9 turns this into a superpower).

The stack also explains the phrase single-threaded from lesson 2.5 more deeply. JavaScript has exactly ONE call stack. So: exactly one top card, exactly one thing running at any instant.

And the stack has a maximum height — call too deep without finishing anything and the engine throws RangeError: Maximum call stack size exceeded.

Fun fact: that overflowing tower is called a stack overflow — and yes, that’s exactly where the website Stack Overflow got its name. The place every programmer on Earth goes to ask questions is named after the error you just learned to cause. You’ll visit it roughly forever.

your turn

⌨️ the same frame, twice

A twist the watched code never showed: one function called TWICE from inside another. Two separate frames for the same function — trace the pushes and pops before you run.

requirements:

A function named chorus whose body prints exactly la la la.
A function named song whose body, in order: prints verse, calls chorus(), calls chorus() again, prints verse.
Call song() once. Before running: how many times does a chorus frame get pushed and popped?

when you press RUN, the console must show exactly:

verse

la la la

verse

✏️ Quick check 1

While boilWater is running, how many function cards are on the stack (not counting the global floor)? Type the number.

✏️ Quick check 2

Type exactly what prints FIRST when makeTea() runs:

✏️ Quick check 3

boilWater finishes and its card pops. Type the name of the function the engine resumes:

teach it back

🗣️ Now teach it back

Explain the call stack to a friend with the tower-of-cards picture: what happens on a call, what happens on a finish, and how the engine knows exactly where to resume.

Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.

a few sentences, minimum — you’ve got this

to remember

Every CALL puts a frame (card) on the stack: its variables + the exact line to resume. Finish = the card pops.

Top card runs; every card below is frozen mid-line, waiting. LIFO — last in, first out.

One stack → one top card → one thing running: that’s "single-threaded", seen from the inside.

Fun fact: the website Stack Overflow is named after the too-tall-tower error you can now explain.

next: 3.7 Closures →