Technology  /  JavaScript

🟨 JavaScript 15 guides · updated 2026

Closures, the event loop, promises, and modern ES syntax — the language of the web explained the way it actually behaves at runtime.

JavaScript Closures Explained: Private State, Factories, and Interview Answers

Closures are JavaScript’s most mythologized concept — the perennial interview question, the topic tutorials save for “advanced” chapters, the word that makes newcomers brace themselves. The mythology is unearned: if you understood lexical scope, you’re one sentence away from closures.

Here’s the sentence: a function keeps access to the variables of the scope where it was defined, even after that scope’s function has returned.

That’s the whole mechanism. This guide makes it concrete, then shows why it matters — closures are how JS does private state, configuration, callbacks-with-context, and memoization. You’ve almost certainly used closures already; by the end you’ll wield them deliberately.

The Canonical Demonstration

function makeCounter() {
  let count = 0;                 // local to this call of makeCounter


  return function () {           // this inner function "closes over" count
    count += 1;
    return count;
  };
}


const counter = makeCounter();   // makeCounter has now RETURNED...
counter();   // 1                // ...yet count is alive
counter();   // 2
counter();   // 3


const other = makeCounter();     // a fresh call → a fresh count
other();     // 1
counter();   // 4                // independent!

Walk through what should feel surprising: makeCounter finished executing — in most mental models, its local variables should be gone. But the returned function still reads and writes count, and keeps doing so across calls.

The resolution: JavaScript functions carry a reference to the environment where they were created — the set of variables in scope at their birthplace. As long as the function is alive, its environment stays alive. counter isn’t a function plus a copy of count; it’s a function plus a live link to the actual variable. That package — function + birth environment — is a closure.

Three consequences, all visible above:

  1. The variable persists — garbage collection spares whatever a living function can still reach (same reachability logic as any GC).
  2. The link is live, not a snapshot — count += 1 mutates the one true count; the next call sees the update.
  3. Each factory call creates a fresh environment — counter and other close over different count variables. Closures are per-creation, not per-function-definition.

And the punchline most people miss: count is now genuinely private. No code anywhere can read or modify it except through the returned function. Before classes had #private fields, this was JavaScript’s privacy mechanism — and it remains airtight and idiomatic.

You’ve Been Using Closures All Along

Closures aren’t a special construct you opt into — every function that references an outer variable is one. Which means they’re everywhere:

// Every event handler that uses surrounding data
function setupBuyButton(product) {
  button.addEventListener("click", () => {
    addToCart(product.id);          // closure over product — alive as long as the handler is
  });
}


// Every async callback that remembers context
function fetchUser(id) {
  return fetch(`/api/users/${id}`)
    .then((res) => res.json())
    .then((user) => {
      console.log(`Loaded user ${id}:`, user.name);   // id survives the network wait
    });
}


// Every array-method callback using outer values
const minPaise = 50_000;
const bigOrders = orders.filter((o) => o.paise > minPaise);  // closes over minPaise

This is the mental reframe worth having: closures are how callbacks carry context. The event fires minutes later, the network responds seconds later, and the callback still knows which product, which id, which threshold — because it closed over them. Without closures, every callback API would need explicit context-passing machinery (and in languages without them, it does).

Patterns Built on Closures

Function factories (configuration)

const makeFormatter = (currency, locale) => (paise) =>
  new Intl.NumberFormat(locale, { style: "currency", currency }).format(paise / 100);


const inr = makeFormatter("INR", "en-IN");
const usd = makeFormatter("USD", "en-US");
inr(499900);   // "₹4,999.00"
usd(499900);   // "$4,999.00"

Configure once, use many times. The returned function is specialized by its closed-over settings — this is the factory pattern from the functions guide, now with its mechanism explained.

Encapsulated state machines

function createRateLimiter(maxCalls, windowMs) {
  let timestamps = [];                          // private history


  return function canProceed() {
    const now = Date.now();
    timestamps = timestamps.filter((t) => now - t < windowMs);
    if (timestamps.length >= maxCalls) return false;
    timestamps.push(now);
    return true;
  };
}


const allowRequest = createRateLimiter(5, 60_000);   // 5 calls per minute

Real utility, ~10 lines, zero classes — and timestamps is untouchable from outside. Debouncing, throttling, caching, ID generation: the “small stateful utility” niche belongs to closures.

Memoization (caching by closure)

function memoize(fn) {
  const cache = new Map();                      // private cache
  return function (arg) {
    if (!cache.has(arg)) cache.set(arg, fn(arg));
    return cache.get(arg);
  };
}


const slowSquare = (n) => { heavyWork(); return n * n; };
const fastSquare = memoize(slowSquare);
fastSquare(9);   // computes
fastSquare(9);   // instant — cache hit

memoize is a higher-order function and a closure factory: the returned wrapper closes over both fn and cache. This exact shape — wrap a function, add behavior via closed-over state — generalizes to logging wrappers, retry wrappers, and once-only guards (once(fn)), and it’s how much of the utility-library ecosystem is built.

The Pitfalls (Interview Section)

The loop capture classic. Fully explained in the scope guide, it’s really a closure question:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 10);   // 3, 3, 3 — three closures, ONE shared var i
}
for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 10);   // 0, 1, 2 — let: one i PER iteration
}

The interview phrasing to internalize: closures capture variables, not values. Three arrows closed over the same var i see its final value; let’s per-iteration binding gives each closure its own variable. If asked to fix the var version without let, the historical answer is an IIFE creating a scope per iteration — worth being able to sketch.

Stale closures. The subtler modern version — a long-lived callback capturing a variable that later “should” be newer:

let user = { name: "Ada" };
setInterval(() => console.log(user.name), 5000);  // fine: closes over the BINDING, sees updates
// but:
function start(u) {
  setInterval(() => console.log(u.name), 5000);   // u is fixed to whoever start() got called with
}

Whether a closure sees updates depends on which variable it closed over — an outer mutable binding (sees changes) versus a parameter frozen at call time (doesn’t). This exact distinction resurfaces as React’s “stale closure” hook bugs; the JS-level understanding is the cure.

Memory retention. A closure keeps its whole birth environment reachable — usually microscopic, occasionally not. A handler that closes over a huge parsed dataset (because it uses one field) pins the entire dataset for the handler’s lifetime. The fix mirrors Java’s leak advice: close over the little you need (const label = data.label; then use label), and remove listeners you no longer need.

How to Answer “What Is a Closure?” in an Interview

A tiered answer that lands:

  1. Definition (one line): “A closure is a function bundled with the lexical scope it was created in — it retains access to those variables even after the outer function returns.”
  2. Demonstrate: sketch makeCounter, point at the persistence and the privacy.
  3. Show you’ve used them: “Practically, closures are how callbacks carry context — event handlers remembering which item they belong to, async code remembering its request ID — and how we build factories and memoization.”
  4. Show you know the edges: mention capture-by-variable (the var loop), stale closures, or retention if invited deeper.

The differentiator between memorized and understood is step 3 — connecting the mechanism to code you write daily.

Seeing Closures in DevTools

Closures stop being abstract the day you inspect one. Set a breakpoint inside any callback (or console.dir a function), and the Scope panel shows the layers this guide described: Local (the function’s own variables), one or more Closure sections (the captured environments, listed per enclosing function), then Script/Global. console.dir(counter) on the makeCounter example exposes [[Scopes]] with count sitting in a Closure entry — the “function plus birth environment” package, rendered literally. Two practical uses: verifying what a suspicious callback actually captured (stale-closure hunts start here), and noticing when a closure retains something huge you didn’t intend (the retention pitfall, visible as a fat object in the Closure scope). Engines do optimize captures — variables provably unused by any inner function may be dropped from the environment — which is why the panel sometimes shows less than the source suggests; the observable rule stands: what a living function can reach, stays alive.

Frequently Asked Questions

Do closures make my code slow? No, in any way you’ll measure — environments are cheap, engines optimize aggressively, and closures often replace heavier machinery (classes, context objects). Retention (holding big data alive) is the only real cost, and it’s a design issue, not an execution one.

Is every function a closure? Effectively, in JS — even “non-capturing” functions technically reference module/global scope. The term is usually reserved for functions whose captured variables matter, but there’s no separate species; it’s one mechanism, always on.

Closures vs classes for private state — which? Closures win for single-method utilities and function-shaped APIs (limiters, formatters, memoizers); classes win for many-method entities with shared behavior across many instances. They’re complementary; modern codebases use both, and #private fields removed classes’ old privacy disadvantage.

Can two functions share one closure? Yes — return two functions from the same factory and they close over the same environment:

function makeAccount(openingPaise) {
  let balance = openingPaise;
  return {
    deposit: (p) => (balance += p),
    getBalance: () => balance,
  };
}

deposit and getBalance share the same live balance — a two-method “object with truly private state,” built from nothing but functions. This shape (the “module pattern”) organized JavaScript for a decade before ES modules — and a module’s top-level state with exported functions is, conceptually, this same pattern at file scale.

Closures You’ll Write This Month: Debounce and Throttle

The two most-implemented closure utilities in front-end work deserve full treatment, because you’ll either write or configure them within weeks:

function debounce(fn, waitMs) {
  let timer;                                    // private, per-debounced-function
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), waitMs);
  };
}


function throttle(fn, intervalMs) {
  let last = 0;
  return function (...args) {
    const now = Date.now();
    if (now - last >= intervalMs) {
      last = now;
      fn.apply(this, args);
    }
  };
}


searchInput.addEventListener("input", debounce(runSearch, 300));  // after typing pauses
window.addEventListener("scroll", throttle(updateProgress, 100)); // at most 10×/sec

Debounce: reset a timer on every call; only a pause lets it fire — right for “react to the final state” (search-as-you-type, resize handling, autosave). Throttle: enforce a minimum gap — right for “react continuously but boundedly” (scroll positions, drag events). Both are pure closure engineering: the returned function carries private state (timer, last) across calls, exactly the makeCounter mechanism doing production work. Note the details that distinguish solid implementations from snippets: ...args forwarding, and fn.apply(this, args) preserving whatever this the wrapper is called with — so the utilities work on methods, not just free functions.

One habit: create the debounced function once and reuse it. addEventListener("input", debounce(run, 300)) inside a render loop creates a fresh debounced wrapper (with fresh empty state) every render — the debouncing silently stops working. The closure’s state lives in the wrapper instance; keep the instance.

Self-Check

// 1. What prints, and why?
function outer() {
  let x = 10;
  const get = () => x;
  x = 20;
  return get;
}
console.log(outer()());


// 2. What prints?
const fns = [];
for (var k = 0; k < 3; k++) fns.push(() => k);
console.log(fns.map((f) => f()));


// 3. Design: write once(fn) — a wrapper that calls fn the first time,
//    then returns the first result forever after. (Three lines, one closure.)

Answers: (1) 20 — closures capture the variable, not its value at capture time; the reassignment before return is visible. (2) [3, 3, 3] — the var trap in array form. (3) const once = (fn) => { let done = false, result; return (...a) => (done ? result : (done = true, result = fn(...a))); }; — closed-over done/result are the private memory.

Next in the core-concepts arc: The this Keyword — the other famous interview topic, and the one place where “where a function is written” stops being the whole story.