Closures

1Definition

A closure is a function bundled together with references to its surrounding lexical scope. The function keeps access to variables from the scope it was created in, even after that outer scope has finished executing.

function makeGreeter(greeting) {
  return function (name) {
    return `${greeting}, ${name}!`;
  };
}

const greetHello = makeGreeter("Hello");
console.log(greetHello("Ana")); // "Hello, Ana!"

makeGreeter("Hello") returns and its call stack frame is gone — yet the inner function still reaches greeting. That's the closure at work: it didn't copy the value, it kept a live reference to the variable.

2How This Works Mechanically

Every function created in JavaScript carries an internal reference to the lexical environment it was defined in. As long as any reference to the inner function exists, that environment (and everything it needs) is kept alive by the garbage collector — it is not destroyed just because the outer function returned.

function counter() {
  let count = 0;
  return {
    increment: () => ++count,
    decrement: () => --count,
    value: () => count,
  };
}

const c = counter();
c.increment();
c.increment();
console.log(c.value()); // 2

All three inner functions share the same closure over count — they read and write the same live variable, not separate copies.

3Closures Capture Variables, Not Values

This is the single most important — and most misunderstood — fact about closures.

function badLoop() {
  var fns = [];
  for (var i = 0; i < 3; i++) {
    fns.push(() => console.log(i));
  }
  fns.forEach(fn => fn()); // 3, 3, 3 — NOT 0, 1, 2
}
badLoop();

Because var i is function-scoped, all three closures capture the same i. By the time the callbacks run, the loop has finished and i is 3.

function goodLoop() {
  var fns = [];
  for (let i = 0; i < 3; i++) {
    fns.push(() => console.log(i));
  }
  fns.forEach(fn => fn()); // 0, 1, 2 — correct
}
goodLoop();

let creates a new binding of i for every iteration, so each closure captures its own independent variable.

4Practical Use: Data Privacy

Because a closure's captured variables aren't accessible from outside, closures are the standard way to create private state in JavaScript without classes:

function createBankAccount(balance) {
  return {
    deposit(amount) { balance += amount; return balance; },
    getBalance() { return balance; },
  };
}

balance cannot be read or modified except through the returned methods — there is no account.balance property at all.

⚠️ Common Pitfalls

1. Loop variable capture with var — the #1 closure bug. Fix with let, or by wrapping in an IIFE that captures the value per iteration.
2. Assuming a closure snapshots a value — it doesn't; it holds a live reference. If the outer variable changes later, every closure over it sees the new value.
3. Memory leaks from long-lived closures — a closure keeps its entire lexical environment alive, not just the variables it uses. Holding a reference to a large object in an outer scope keeps it in memory as long as any inner closure exists.

1What a Closure Actually Keeps Alive

A closure does not selectively keep only the variables it references — in most engines it keeps the entire lexical environment record of the enclosing scope reachable. Two consequences:

function outer() {
  const bigArray = new Array(1_000_000).fill("data"); // large
  const smallValue = 1;

  return function inner() {
    return smallValue; // only uses smallValue...
  };
}

const fn = outer(); // ...but in older/naive engines bigArray may be retained too,
                     // because inner and bigArray share the same environment record.

Modern V8 performs closure optimization and can discard genuinely unreferenced bindings, but you should not rely on this — don't hold large objects in a scope that a long-lived closure shares, if you can avoid it. Extract only what you need into a smaller scope first.

2Module Pattern (Pre-ES-Modules Encapsulation)

Before ES modules existed, closures were the primary way to build private state and a public API from an IIFE:

const Counter = (function () {
  let count = 0; // private, invisible outside this IIFE
  return {
    increment() { return ++count; },
    reset() { count = 0; },
  };
})();

Counter.increment(); // 1
Counter.increment(); // 2
Counter.reset();

3Memoization

Closures let a function remember results of previous calls in a private cache:

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;
  };
}

cache is private to each memoized function instance — inaccessible and untamperable from outside.

4Partial Application / Currying

function multiply(a) {
  return function (b) {
    return a * b;
  };
}

const double = multiply(2);
double(5); // 10

double is a closure that "remembers" a = 2 permanently.

5Once-Only Execution

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

called and result persist across calls to the returned function because of the closure, even though once() itself only runs a single time.

6Closures vs Classes for Private State

For a handful of stateful objects, closures are fine. For thousands of instances, class-based private fields are more memory-efficient because methods live once on the prototype instead of being recreated per closure.

function outer() {
  const captured = "kept alive";
  const notCaptured = "discarded when outer() returns";

  return function inner() {
    return captured; // only THIS variable forces a heap Context
  };
}

function outer() {
  const bigArray = new Array(1_000_000).fill(0); // large
  const smallFlag = true;

  return function inner() { return smallFlag; }; // only touches smallFlag
}

function counter() {
  let count = 0; // a NEW Context object is allocated on EVERY call to counter()
  return () => ++count;
}
const c1 = counter();
const c2 = counter();

⚠️ Common Pitfalls (continued)

1. Creating closures inside hot loops — every call to an outer function creates new function objects for its closures; doing this in a tight loop (e.g. attaching a new closure per array element per frame) can hurt performance.
2. Forgetting closures are per-call, not per-function — calling counter() twice produces two independent closures over two independent count variables.
3. Debugging "stale" values — if a closure appears to read an old value, check whether you intended to capture a snapshot (you didn't — closures are always live) versus a fresh variable per iteration (need let, not var).

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

Source: js_closures_theory_1.md, js_closures_theory_2.md · generated by tools/build_lessons.py