# Clarifying JavaScript Closures — narration script

Runtime 4:18. Timecodes are when each chapter starts; the film's animation is keyed to these cue times, so a recorded voice-over should keep each line near its timecode.

## 0:00 · What should happen to a local variable

- `0:01` Look at this function makeCounter. It creates a local variable, count, which is set to zero. Then it creates a second function inside itself, and returns that function without running it.
- `0:18` You already know what happens to a local variable when its function returns. It's gone. So look at what that inner function is about to do. It adds one to count, but how? Hasn't count already gone away?

## 0:36 · It stays

- `0:36` The truth is that the local variable actually doesn't go away because of something called a closure. In JavaScript, a closure is an inner function that retains variables from the place it was created. Name the returned function tally.
- `0:55` In many languages, a local variable lives and dies with the call. In JavaScript, the variable lives for as long as something can still reach it, and the function tally can reach it.
- `1:09` Call tally. One. Call it again. Now it is two. Again. Three. makeCounter finished long ago, and yet count is still there, keeping its value between calls.

## 1:26 · The variable, not a copy

- `1:26` Call makeCounter a second time and you get a new box, with its own count. Each one counts separately, because they don't share anything.
- `1:37` The function holds the variable itself, not a snapshot of its value. That's why each call sees what the last call left.
- `1:48` And no one else can get in. Ask tally for a count property, and you get undefined. The only way to that variable is through the function, so no other code can touch it.

## 2:02 · You already use closures

- `2:02` You use these every time you hand a function to the browser, to run on a click, a timer, or a response from the network. By the time it runs, the code that created it has finished. It reaches those variables through its closure. That's why closures were fundamental to JavaScript-powered HTTP communications, often dubbed Ajax, and they still are.

## 2:29 · Troubling loops

- `2:30` Now the bug that caught JavaScript programmers for years. This loop sets three timers, and each should print its own pass through the loop: zero, one, two. It prints three, three, three.
- `2:47` You now know why. The var statement has function scope, so there's one variable named i, and all three functions hold that same variable. The timers run after the loop ends, and by that point the value of i is three. Each function is reading the variable as it is now, and not as it was.

## 3:09 · Fixed with a new declaration

- `3:10` Change the declaration from var to let. The let at the head of a for loop gives each pass a new variable, so there are three boxes now, and each function holds its own. Zero, one, two. The functions didn't change. What changed is how many variables they had to hold.

## 3:31 · Is there a cost?

- `3:32` There's a cost, and it follows from the same rule. What a closure can reach can't be collected while the closure itself can be reached. A handler you never remove can hold on to its variables for the life of the page, which can lead to a memory leak, so make sure you understand closures and clean up after yourself.
- `3:56` So when you look over closures, ask the question, "Which variable does this function hold on to, and who else is holding it?" Try the playgrounds in the Functions and Closures article, and explore this powerful idea yourself.