What Happens When a Function Runs: Execution Contexts and Closures

Every function call creates an execution context: a record of where execution is, which variables exist and what this is. Variables live in environments linked in a chain that follows how your code is nested on the page, not how it is called. A closure is what you get when a function outlives the call that created it and keeps that link. Hoisting, scope, closures and the classic “loop prints 3, 3, 3” bug are all the same model, and this post walks through it with diagrams.

Why It Matters

Closures power callbacks, event handlers, React hooks, memoization, private state and module patterns. When they go wrong, you get:

• stale values in a setTimeout
• a React effect that reads an old prop
• memory that never gets freed

All of these become predictable once you can picture which environment a function holds.

The Call Stack and Execution Contexts

When JavaScript starts running a script or module, it creates a global (or module) execution context. Each function call pushes a new context onto the call stack; returning pops it off:

function total(items) {
  return items.reduce(add, 0);
}
function add(sum, n) {
  return sum + n;
}
total([1, 2, 3]);

Each context has three main parts:

• a lexical environment: the variables declared in that call
• a reference to the outer environment
• a this value

The stack has a size limit, and infinite recursion ends with RangeError: Maximum call stack size exceeded.

Creation, Then Execution

When a context is created, the engine first creates bindings for every declaration in that scope, then runs the code. That is what “hoisting” really means:

The kinds of scope (global, module, function and block), shadowing and the temporal dead zone each have more rules and traps than fit here. They have their own post: scope, hoisting and the temporal dead zone.

The Scope Chain

Every environment points to its outer environment, the one where its code was written. Looking up a name walks outward until it is found:

let x = 'global';
function outer() {
  let x = 'outer';
  return function inner() {
    return x;
  };
}
outer()(); // 'outer'

Blocks such as if, for and { … } add environments of their own for let, const and class, so the chain often has more links than there are functions. This is lexical scope: inner looks in the environment where it was written, regardless of who calls it. The one thing that does depend on the call is this, covered in JavaScript’s this keyword, four rules and one exception.

A function can use a variable declared below it, as long as the line has run before the function is called:

function show() {
  return y;
}
let y = 'defined later';
show(); // 'defined later'

Closures: Functions That Keep Their Environment

Normally a call’s environment is discarded when the call returns. But if a function created inside it is still reachable (returned, stored or passed as a callback), that function keeps a link to the environment, and so the environment stays alive:

function makeCounter() {
  let count = 0;
  return {
    inc: () => ++count,
    get: () => count,
  };
}
 
const a = makeCounter();
const b = makeCounter();
a.inc();
a.inc();
b.inc();
a.get(); // 2
b.get(); // 1

Each call to makeCounter creates a separate environment with its own count. Both functions returned from one call share that one environment, which is how they see each other’s changes. This is the classic way to get truly private state.

Closures You Already Use

Many everyday helpers are closures that keep a little private state between calls. once remembers whether it has run:

function once(fn) {
  let called = false;
  let result;
  return (...args) => {
    if (!called) {
      called = true;
      result = fn(...args);
    }
    return result;
  };
}
 
const init = once(() => console.log('initialized'));
init(); // logs 'initialized'
init(); // does nothing

debounce remembers the pending timer, so only the last call in a burst runs:

function debounce(fn, ms) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), ms);
  };
}
 
const search = debounce((query) => console.log('search', query), 300);
search('r');
search('re');
search('react'); // only 'search react' runs, 300 ms after the last call

Each call to once or debounce creates a fresh environment, so two debounced functions never share a timer.

The Loop That Prints the Same Number

const withVar = [];
for (var i = 0; i < 3; i++) withVar.push(() => i);
withVar.map((f) => f()); // [3, 3, 3]
 
const withLet = [];
for (let j = 0; j < 3; j++) withLet.push(() => j);
withLet.map((f) => f()); // [0, 1, 2]

var is function-scoped, so there is one i shared by all three closures, and it is 3 when they run. let in a for loop creates a fresh binding for each iteration, so each closure captures its own j.

Stale Closures in React

The same rule explains “stale” values in hooks. A callback created during one render closes over that render’s props and state:

function Timer() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => setCount(count + 1), 1000); // count is always 0 here
    return () => clearInterval(id);
  }, []);
}

The effect ran once, so its closure holds the count from the first render. Use the updater form (setCount((c) => c + 1)) or list count as a dependency.

Closures and Memory

An environment stays in memory as long as something can reach a closure that uses it. That is normally exactly what you want, but long-lived holders turn it into a leak:

Engines only keep the variables closures can actually use, but closures created in the same scope can share one environment, so a small long-lived closure may keep a large object alive that only a sibling closure used. The fix is the same as for any leak:

• remove listeners (an AbortController makes this easy)
• clear timers
• avoid capturing large objects in long-lived callbacks

The memory management post covers how to find these leaks.

Going Deeper: What the Engine Actually Keeps

The diagrams above describe the language. Engines implement it more cleverly, and knowing how explains both the performance and the memory behaviour of closures.

• Only captured variables move to the heap. V8 analyses each function when it is compiled. Variables no inner function uses stay in fast stack slots and vanish when the call returns. Variables an inner function does use go into a heap-allocated context object that outlives the call.
• Siblings share one context. All closures created in the same scope point to the same context object. That is why a small, long-lived callback can keep a large object alive if any sibling closure in that scope used it (the leak described above).
• You can inspect it. In Chrome DevTools, expand a function in the console or the Scope panel and look at its [[Scopes]]: it lists exactly which environments, and which variables, the function keeps.

Closures, classes with #private fields and module scope can all hide state. Which to use is mostly a design choice:

Creating closures is cheap, but not free. In a hot loop or a React render, a new function is a new identity every time, which defeats memoization (React.memo, dependency arrays) rather than costing much CPU. Reach for useCallback or hoisting a function out of the loop when identity matters, not by default.

Test Yourself

Predict the output, then open the answer. Every answer was checked by running the code.

function makeCounter() {
  let n = 0;
  return () => ++n;
}
const a = makeCounter();
const b = makeCounter();
a();
a();
console.log(a(), b());

let greeting = 'Hello';
const greet = (name) => greeting + ', ' + name;
greeting = 'Hi';
console.log(greet('Ada'));

const fns = [];
for (var i = 0; i < 3; i++) fns.push(((j) => () => j)(i));
console.log(fns.map((f) => f()));

function account() {
  let balance = 0;
  return { deposit: (x) => (balance += x), read: () => balance };
}
const acct = account();
const { deposit, read } = acct;
deposit(50);
console.log(read(), acct.balance);

function once(fn) {
  let done = false;
  return (...args) => {
    if (done) return 'skipped';
    done = true;
    return fn(...args);
  };
}
const init = once(() => 'ran');
const again = once(() => 'ran');
console.log(init(), init(), again());

Key Takeaways

Sources

• V8 blog: Blazingly fast parsing, part 2: lazy parsing (how V8 finds which variables closures capture)
• MDN: Private properties
• ECMAScript specification: Execution contexts and Environment records
• MDN: Closures
• MDN: let: temporal dead zone
• React docs: Updating state based on the previous state