Closures in Loops

Foundational

The classic interview question: why do all your loop callbacks print the same value? Understanding this unlocks how closures really work.

The var Trap

With var, all iterations share the same variable. By the time the callbacks execute, the loop is finished and i is already at its final value:

var-loop.js

// THE TRAP — var is function-scoped
for (var i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(i); // all print 3!
  }, 100);
}
// There's only ONE 'i', and it's 3 by the time callbacks run

See It Live

Watch the difference between var and let in real time. Each button schedules 3 timeouts — but the results are very different:

varShared binding

Waiting for callbacks...

letUnique binding per iteration

Waiting for callbacks...

The let Fix

let is block-scoped: each loop iteration creates a new binding. Each closure captures its own unique copy:

let-loop.js

// THE FIX — let is block-scoped
for (let i = 0; i < 3; i++) {
  setTimeout(() => {
    console.log(i); // prints 0, 1, 2 ✅
  }, 100);
}
// Each iteration creates its own 'i' — a new capsule each time

The Old-School Fix: IIFE

Before let existed, developers used an Immediately Invoked Function Expression (IIFE) to create a fresh scope per iteration:

iife-fix.js

// Pre-ES6 fix: IIFE creates a new scope per iteration
for (var i = 0; i < 3; i++) {
  (function (captured) {
    setTimeout(() => {
      console.log(captured); // prints 0, 1, 2 ✅
    }, 100);
  })(i);
}

Summary

var is function-scoped — one variable shared across all iterations
let is block-scoped — each iteration gets its own binding (its own time capsule)
Closures capture variables by reference, not by value — that's why var creates a trap
This same principle causes stale closures in React hooks