Closures in loops, timers & memory

When closures surprise you

A closure is a function together with the variables around the place where it was made. Every function you write is a closure. It can still use those outside variables later, even after the outer code has finished.

This is what makes many everyday tools work:

• callbacks, which are functions you hand to other code to call later,
• functions that make other functions,
• private data that only a few functions can change,
• caches, which keep saved results so a function does not work them out twice,
• event handlers, which run when the user clicks or types.

The surprise is this: a closure keeps the variable itself, not a copy of its value. The spec calls such a variable a binding: a name joined to a value. Three things can go wrong:

• The function runs later, and the variable has changed by then.
• The app put a new object in a different variable, but the function still reads the old object.
• The function stays around for a long time, so everything it uses stays in memory too.

The Closures lesson showed that a closure keeps variables, not copies of values. This lesson shows the four places where that causes real bugs: callbacks made in loops, timers, callbacks that read old data, and memory that is kept by mistake.

The best-known closure puzzle fits in three lines. The loop asks for three timers, and each timer prints i. With var, the timers print 3, 3, 3. With let, they print 0, 1, 2. The timer functions are the same in both. The difference is how many variables named i there are.

Run the replay below twice. First leave it on var and watch the one i change. Then switch to let. Each timer now points at its own i from its own loop step.

1for (var i = 0; i < 3; i++) {Run2  setTimeout(() => console.log(i), 0);3}

You will learn timers fully in Stage 6, in the Timers and Event loop lessons. For now, one rule is enough:

• setTimeout(fn, delay) asks the browser (or Node.js) to call fn later.
• JavaScript does not wait. It goes on with the next line straight away.
• So a loop always finishes before any of its timer functions run.

The timer function is made during the loop. The console.log inside it runs later. That gap in time is the whole trick.

console.log("before");
setTimeout(() => console.log("timer"), 0);
console.log("after");

Line by line:

1. Line 1 prints before straight away.
2. Line 2 hands a function to setTimeout. The function waits until the script is done.
3. Line 3 prints after straight away.

Only then does the timer function run and print timer. A delay of 0 milliseconds means "as soon as possible after this code", not "now".

Every good fix does one of two things. It gives each callback its own new variable, or it hands the callback the value as it is right now. Here are the four fixes you will meet:

• let in the loop header. This is what modern code uses.
• An IIFE. IIFE is short for "Immediately Invoked Function Expression": a function that is called right where it is written. Older code uses it.
• An extra argument to setTimeout. Values you write after the delay are passed into the timer function when it runs.
• forEach. This array method calls your function once per item, and each call gets its own parameter.

The table puts the four fixes side by side. Read each row from left to right: the fix, why it works, and where you will see it.

1for (var i = 0; i < 3; i++) {Run2  setTimeout((n) => console.log(n), 0, i);3}

"Stale" means old and out of date. A stale closure is a callback that reads data that was right when the callback was made, but is not the current data any more.

This happens a lot in web pages. Apps often change their data by making a brand-new object, instead of changing the old object. A callback that saved the old object keeps reading it.

In the example below, the variable settings gets a new object. The callback reads captured instead, and captured still holds the first object.

1let settings = { label: "slow" };Run2 3function startTicker() {4  const captured = settings;5  return () => console.log(captured.label);6}7 8const tick = startTicker();9settings = { label: "fast" };10tick();

let user = { name: "Asha" };

function registerClick() {
  const captured = user;
  return () => console.log("Hello", captured.name);
}

const handleClick = registerClick();
user = { name: "Noor" };
handleClick();

This code has the same shape as a button's click handler. A click handler is a function the page runs when someone clicks.

1. Line 1 makes user, with the name Asha.
2. Line 4 saves that object in captured.
3. Line 9 gives user a new object, with the name Noor.
4. Line 10 "clicks". The handler reads captured, so it prints Hello Asha.

A real click works by the same closure rules. The only difference is that the delay is longer, so the bug is easier to miss.

let settings = { label: "slow" };

function startTicker() {
  const captured = settings;
  return () => console.log(captured.label);
}

const tick = startTicker();
settings = { label: "fast" };
tick();

The Memory: primitives vs objects lesson explains how JavaScript frees memory. Here is the short version:

• A value is reachable if your code can still get to it, through some chain of variables.
• JavaScript frees a value only when nothing can reach it. This is called garbage collection.
• A function that stays around is reachable. So the variables it uses stay reachable too.

function makeReport() {
  const rows = new Array(1_000_000).fill("row");
  return () => rows.length;
}

const report = makeReport();
console.log(report());

The table lists four common ways memory gets kept. Read each row from left to right: what your code has, why its memory stays, and how to fix it.

function makeReport() {
  const rows = new Array(1_000_000).fill("row");
  return () => rows.length;
}

const report = makeReport();
console.log(report());

Line 2 makes an array with a million items. Line 3 returns a function that reads rows.length. That small function uses rows, so the whole array can stay in memory for as long as report exists.

function makeReport() {
  const rows = new Array(1_000_000).fill("row");
  const rowCount = rows.length;
  return () => rowCount;
}

const report = makeReport();
console.log(report());

Line 3 copies the length into rowCount, a single number. Line 4 returns a function that reads only rowCount. Both versions print 1000000, but this one no longer needs the array.

Sometimes you keep data in a closure on purpose, such as a cache. Then make it a clear choice:

• limit how many results it can hold,
• give it a clear method to empty it, or
• use a WeakMap when the keys are objects, so the cache alone does not keep those keys in memory.

The later Finding memory leaks lesson shows how to prove this in a real app with heap snapshots. A heap snapshot is a list of every object in memory at one moment.

const panel = document.querySelector("#panel");
const handleClick = () => console.log(panel.textContent);
panel.addEventListener("click", handleClick);
panel.remove();
// The listener still reaches the detached panel until cleanup.

This code only works in a browser. Line by line:

1. Line 1 finds the element with the id panel on the page.
2. Line 2 makes a click handler that uses panel.
3. Line 3 adds the handler to the element.
4. Line 4 removes the element from the page. A removed element like this is called detached.

The handler still uses panel, so the element can stay in memory. To check, open DevTools, take a heap snapshot, search for Detached, and look at what still points at it. To fix it, remove the listener (or abort its signal) when you remove the feature.

Where you will use this

These rules matter whenever code runs later than the place where it was written:

• timers and repeating timers,
• event listeners and click handlers,
• animation callbacks,
• retries after a failed request,
• code that subscribes to updates.

When you debug these, write down two moments: when the callback was made, and when it actually ran.

function startPolling(readUrl) {
  const id = setInterval(() => {
    console.log("poll", readUrl());
  }, 1000);

  return () => clearInterval(id);
}

"Polling" means asking for new data again and again. Line by line:

1. Line 2 starts a repeating timer with setInterval and saves its id in id.
2. Line 3 runs every second. It calls readUrl(), so it gets the current URL each time, not an old one.
3. Line 6 returns a stop function. It uses id on purpose, to stop the timer with clearInterval.

Once the timer is stopped, nothing keeps its function alive, so its memory can be freed.

let selectedUser = "none";

function makePanel(name) {
  return {
    select() { selectedUser = name; },
    read() { return selectedUser; },
  };
}

const leftPanel = makePanel("Asha");
const rightPanel = makePanel("Noor");
leftPanel.select();
console.log(rightPanel.read());

makePanel makes a new panel object each time you call it. The two panels look separate, but selectedUser is outside makePanel, on line 1. Both panels use that one variable. So when the left panel selects Asha on line 12, the right panel reads Asha too.

The fix is to move selectedUser inside makePanel. Then each call makes its own variable, and each panel keeps its own choice.

function makePanel(name) {
  let selectedUser = "none";
  return {
    select() { selectedUser = name; },
    read() { return selectedUser; },
  };
}

const leftPanel = makePanel("Asha");
const rightPanel = makePanel("Noor");
leftPanel.select();
console.log(rightPanel.read());

Common misconceptions

• "Closures copy values." They keep the variable itself. If the variable changes, the closure reads the new value later.
• "setTimeout with 0 runs right away." It still waits until the code that is running now has finished.
• "const stops stale closures." const only stops you from putting a new value in that variable. It does not freeze an object, and it does not update old callbacks.
• "let makes timers run right away." let only changes which i each timer reads. The timers still run later.
• "JavaScript frees anything I am not using." It frees only values that nothing can reach. A closure, listener, timer, or cache can keep a value reachable.

Key takeaways

• With var in a loop, all callbacks share one i. With let in the loop header, each loop step gets its own i.
• setTimeout functions run later, after the current loop or function has finished.
• A stale closure reads an old variable or object that your code no longer updates.
• A function that stays around keeps the values it uses in memory. Copy only what you need, and stop timers and listeners when you are done.

A closure bug is a correct memory of the wrong thing: the wrong variable, the wrong moment, or a value that should have been let go.

Up next: The old var & the global object.