Under the Hood

The big question: “Execution contexts, the call stack, hoisting, prototypes, this”

but why do we need this?

Sooner or later JavaScript will do something that looks impossible: a variable usable “before” the line that creates it, a this that means different things on different days. If you only know syntax, these look like the language being broken. With the hood open, they become predictable — and they happen to be the exact questions JavaScript interviewers love to ask.

in plain words

You can drive a car without knowing what’s under the hood — until it makes a strange noise. This phase opens JavaScript’s hood: how it reads your file in two passes before running it, how every function call stacks a new tray on a pile (the call stack), and how objects quietly inherit abilities from each other.

Nothing new gets built here; instead, things you’ve already seen stop being mysterious. Why can you sometimes use a thing before the line that creates it (hoisting)? Why does the keyword this keep changing meaning? Where do old values go (garbage collection)?

This is also interview country: these exact questions decide “knows JavaScript” vs “memorized JavaScript.” You’ll be in the first group.

words you’ll own after this

call stack

The machine’s pile of “what am I in the middle of?” trays. Calling a function adds a tray; returning removes it.

execution context

The workspace created for each function call — its own variables, its own view of the world.

hoisting

Before running your code, the engine first scans it and registers every declaration. Some things are therefore usable “early.”

this

A special word whose meaning is decided by HOW a function is called, not where it was written.

prototype

An object other objects fall back to: “if I don’t have it, ask my prototype.” How JavaScript shares abilities.

class

Tidier handwriting for building objects with shared methods — under the hood, it’s still prototypes.

garbage collection

The engine’s cleaner: values nothing points to anymore get swept away automatically.

try / catch / finally

Attempt risky code, catch what goes wrong instead of crashing, and finally always runs — cleanup you can count on.

after this phase, you can…

✓Predict the output of hoisting puzzles — and explain the two passes
✓Narrate the call stack for any piece of code
✓Say what this is in each of the four calling styles
✓Explain how a to-do item “knows” methods it never defined (prototypes)
✓Write a class and explain the prototype machinery it’s shorthand for
✓Catch a thrown error with try/catch/finally instead of crashing

this phase’s lab — see it move

✏️ This phase’s interactive lab is still being drawn — it arrives together with the phase’s lessons.

the lessons

5.1
Execution contexts: the two passes
The engine reads your code twice — creation registers names, execution runs lines.
5.2
Hoisting, demystified
var → undefined, let/const → the dead zone, declarations → complete. One table, every puzzle.
5.3
The scope chain, precisely
Every context carries one rope to where it was WRITTEN — lookup walks outward.
5.4
this: the compass
Decided at CALL time, four rules, one arrow exception — the interview classic.
5.5
Prototypes
The hidden link on every object — lookup climbs the chain; methods shared once.
5.6
Classes
Ergonomic handwriting over prototypes: new’s four steps, extends = a longer chain.
5.7
Garbage collection
Reachability: kept if walkable from the roots — why closures live and leaks grow.
5.8
Error handling
throw launches, the stack unwinds, catch snags, finally always — test runners run on this.
5.9
Checkpoint: the explain-it-all interview
Hoisting, this, chains — answered by simulation. Plus a ten-line test runner.