Closures

Nothing gets turned on

A closure is not syntax you write. It is what you already have. Every function, the moment it is created, keeps a link to the environment it was created in — that is just the outer reference from the execution context chapter, sitting there doing nothing interesting.

It only becomes visible when the function outlives the call that made it. Then the link is the only thing keeping that environment alive, and suddenly everyone has a name for it.

function makeCounter() {
  let count = 0;                  // a local. Should die when makeCounter returns.
  return () => ++count;           // but this little function still points at it
}

const next = makeCounter();
next();   // 1
next();   // 2  — count outlived the call that created it

Watch it happen in space

The flat version of this picture is what causes the confusion — it looks like count gets copied into the function. It does not. Drag the scene, or use the sliders, and step through: the call frame goes away, the environment stays, because something in front of it is still holding on.

Now step through it line by line

The 3D scene shows the idea. This player runs the same program the way the engine does, one line at a time. Press Next until counter() returns: its frame turns dashed because the call has ended, yet it is not thrown away.

Why the variable survives at all

In the execution context chapter you learned that a call gets an execution context, and that the context leaves the stack when the call finishes. That is still true — of the stack frame. The frame is bookkeeping: where to return to, what is running. It pops.

The environment — the box holding the actual variables — lives somewhere else, on the heap, and it follows one rule only:

Which is why closures are not free, and why the memory section below is not an afterthought.

A live link, not a snapshot

The most common wrong mental model is that the inner function copies the values it needs. Two functions made in the same call share one environment, and that settles it:

function makeBox() {
  let value = "first";
  return {
    read: () => value,
    write: (v) => { value = v; },
  };
}

const box = makeBox();
console.log(box.read());     // "first"
box.write("second");
console.log(box.read());     // a copy would still say "first"

"second". read and write are two different functions closing over the same box, so a change made through one is visible through the other. If closures copied values, that would be impossible.

Here is the same idea with a bank balance. Both methods point at one frame, and nothing outside can reach balance except through them.

One call, one closure

function makeCounter() {
  let count = 0;
  return () => ++count;
}

const a = makeCounter();
const b = makeCounter();

a(); a(); a();
b();

console.log("a:", a(), " b:", b());   // what happens?

a: 4 b: 2. Two calls, two environments, two completely separate counts. The closure belongs to the call, never to the function you wrote — which is exactly what the last step of the 3D scene was showing.

Dry run: what each call actually incremented

a and b never touch the same count — each call to makeCounter() built a fresh environment, so there were always two separate boxes, not one shared between them.

Step through the same program and compare the two kept frames: each call to makeCounter() left behind its own box.

Five real jobs closures do

Interviews rarely ask "what is a closure". They ask you to build one of these.

1. Factories — functions that build functions

function multiplierOf(factor) {
  return (n) => n * factor;
}

const double = multiplierOf(2);
const triple = multiplierOf(3);
double(5);   // 10 — "factor" is remembered inside double, permanently

2. Privacy — state no outside code can reach

function createAccount(startingBalance) {
  let balance = startingBalance;    // truly private — no this.balance to poke at
  return {
    deposit: (n) => (balance += n),
    getBalance: () => balance,
  };
}

const acct = createAccount(100);
acct.deposit(50);
acct.getBalance();     // 150
acct.balance;          // undefined — there is no way in

This is the oldest privacy mechanism in JavaScript, and still the simplest. Classes got a real one in ES2022 — #private fields — but a closure needs no syntax at all.

3. Memoize — a cache only the function can see

function memoize(fn) {
  const cache = new Map();
  return function (...args) {
    const key = JSON.stringify(args);
    if (cache.has(key)) return cache.get(key);
    const result = fn(...args);
    cache.set(key, result);
    return result;
  };
}

let calls = 0;
const slowSquare = memoize((n) => { calls++; return n * n; });
slowSquare(5);
slowSquare(5);
slowSquare(5);
console.log("real calls:", calls);   // what happens?

1 — the underlying function runs once per distinct set of arguments. cache is closed over by the returned function and nothing else, so no outside code can reach or corrupt it.

4. Once — work that happens a single time

function once(fn) {
  let called = false, result;
  return function (...args) {
    if (!called) {
      called = true;
      result = fn.apply(this, args);
    }
    return result;
  };
}

let inits = 0;
const init = once(() => { inits++; return "ready"; });
console.log(init(), init(), init());
console.log("actual inits:", inits);   // what happens?

ready ready ready, then 1. Every call after the first returns the cached result without re-running fn — the standard shape behind "run this setup exactly once, however many times it is asked for."

5. Debounce and throttle — a timer nobody outside can see

function debounce(fn, delay) {
  let timer;                        // private to the returned function
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

function throttle(fn, interval) {
  let ready = true;
  return function (...args) {
    if (!ready) return;
    ready = false;
    fn.apply(this, args);
    setTimeout(() => { ready = true; }, interval);
  };
}

The loop trap, from the closure side

The var, let and const chapter showed this as a question about how many bindings a loop creates. From here it is the same fact, viewed from the other end: all three callbacks closed over the same environment, so they all read the same box — and by the time any of them ran, the loop had finished writing to it.

for (var i = 0; i < 3; i++) setTimeout(() => console.log(i), 0);   // 3 3 3
for (let j = 0; j < 3; j++) setTimeout(() => console.log(j), 0);   // 0 1 2

One shared box versus a fresh box per iteration. Nothing about the callbacks changed.

Step through both versions. With var there is one i in the global scope. With let every pass gets its own scope, and each callback keeps one of them alive.

See what the callback captured

The same loop twice, one keyword apart. Watch how many bindings each version creates — that is the whole difference.

Closures and memory — the part that bites in production

A closure is a reference, and a reference stops collection. Almost every JavaScript memory leak is a closure that outlived its usefulness while still holding something large.

// The listener never gets removed, so the closure lives forever —
// and it is holding a reference to a huge object it barely uses.
function attach(node, hugeDataset) {
  node.addEventListener("click", () => {
    console.log("clicked", hugeDataset.length);   // keeps hugeDataset alive
  });
}

// Same shape, worse: an interval no one clears keeps its closure,
// its closure keeps the node, and the node may already be off the page.
setInterval(() => update(detachedNode), 1000);

• Remove listeners when the thing they belong to goes away, or use an AbortController signal to drop them all at once.
• Clear intervals and timeouts. An uncleared interval is an immortal closure.
• Do not close over more than you need. Pull out the one field you actually use rather than capturing the whole object.

Engines are smarter than the naive model: V8 captures only the variables a closure actually mentions, not the entire scope. But the ones it does capture are held completely — capture one field of a 10MB object and you keep the field, capture the object and you keep all 10MB. Engine & memory has the heap snapshots that let you see which.

Seeing one for yourself

This is not a metaphor you have to take on faith. Put a debugger statement inside a returned function, run it, and open the Scope panel in DevTools: alongside Local and Global there will be an entry labelled Closure (makeCounter), with the retained variables listed inside it — the middle plane of the 3D scene, printed as a tree.

The traps, collected

• Expecting a snapshot. The closure reads the variable when it runs, not when it was created.
• Sharing an environment by accident. Two functions from the same call share state — sometimes what you want, sometimes a bug.
• Assuming a new closure per loop iteration. Only let and const give you that.
• Leaking through listeners and intervals. The closure cannot be collected while the subscription is alive.
• Thinking it is rare. Every callback, every event handler, every module is a closure. It is the default, not the exception.