Closures

A backpack that stays with the function

Why keep anything after a function returns? A click handler may need a counter between clicks, or a search helper may need a chosen delay. Making all that data global would let unrelated code change it. The backpack lets the function keep just the surroundings it needs.

Two calls, two sets of bindings

The outer call has two jobs: establish its local bindings and create the inner function. The inner function can use those bindings because it was defined inside that scope. Returning the function gives the caller a way to do that work later, without exposing a direct name for the private count.

Creating a function and calling it are separate events. makeCounter creates the inner increment function and returns it without calling it. The next binding then holds that function. Only next() performs an increment. A second call to makeCounter would create a second count and another backpack; it would not reset the first.

What the backpack actually keeps

A binding can survive after its creating call has left the active call stack. It remains available while a reachable function still needs access to it. This retained access is what allows a second click to continue where the first left off.

The backpack is a mental model for retained access, not a literal copy of every value. If two inner functions share one outer binding, a change made through one is visible to the other. This explains why a closure can track changing state instead of always reporting its original value.

Useful private state

This makes closures useful for private counters, configured helpers, and handlers attached to a specific item. Two returned functions from the same outer call can deliberately cooperate through one count. Two separate outer calls have separate local bindings, so creating another counter does not reset the first.

Follow creation separately from use

Closures do not require returning a function; event handlers and callbacks can close over surrounding bindings too. They are useful, but they can also keep large objects reachable longer than expected. Remove unused handlers and timers so an otherwise finished feature can release the state it no longer needs.

Trace the example in two phases. During setup, count starts at zero and next receives the returned function. Later, the first next() changes that same count to one; the second changes it to two. count is not directly readable outside makeCounter, but increment still has access. If that distinction takes a second read, that is the useful part to slow down on.