What is a Closure?

--- title: "What is a Closure?" author: "Generated via Being Zetetic · Zetetic Thread" date: "2026-06-15" geometry: margin=2.2cm fontsize: 11pt --- # What is a JavaScript Closure? > *The most-feared concept in JS, asked and answered. From > "what is a function" to "why does a closure survive".* --- ## 📖 Overview This document walks you, one question at a time, from the most basic idea of a function all the way to why a closure can outlive the function that created it. By the end, you should be able to explain closures to a senior engineer in three sentences, and rebuild the concept from scratch six months from now. --- ## 🧭 Map - **Phase 1.** What is a function, in the most basic sense? - **Phase 2.** Where do a function's variables live while it runs? - **Phase 3.** What happens to a variable that an inner function uses after the outer function has returned? - **Phase 4.** How does JavaScript know to keep a variable alive? - **Phase 5.** Where do closures live in memory? - **Phase 6.** Can closures cause memory leaks? - **Phase 7.** What are closures actually good for? --- ## 🧵 The Thread ### ❓ Phase 1 — Functions > What is a function, in the most basic sense? **Answer.** A function is a named sequence of instructions that can be invoked any number of times, with different inputs, and may return a value. **Why this matters.** The word *function* comes from Latin *functio* — "a performing, an execution." A function is something that performs when called. The inputs are the *arguments*. The output is the *return value*. The list of instructions inside is the *body*. ➡️ **Next question.** When a function runs, where do its arguments and local variables live? --- ### ❓ Phase 2 — Stack frames > Where do a function's variables live while it runs? **Answer.** In a region of memory called a *stack frame*. **Why this matters.** A stack frame is created the moment a function is called and destroyed the moment it returns. The frame holds all the function's local variables, plus the arguments it was called with. Think of a stack of plates: each new function call pushes a new plate; when the function finishes, you take its plate off the stack and throw it away. ➡️ **Next question.** If the frame is destroyed when the function returns, what happens to a variable that an inner function tries to use after the outer function has already returned? --- ### ❓ Phase 3 — Survival > What happens to a variable that an inner function uses after the outer function has returned? **Answer.** Normally, it would be gone. But if the inner function still holds a reference to that variable, the variable is *not* destroyed. It survives. That surviving variable-and-function pair is a *closure*. **Why this matters.** The word *closure* means "closed over" — the inner function "closes over" the outer variables it references, carrying them with it like a backpack. ➡️ **Next question.** If the inner function is the only thing still holding a reference to the outer variable, how does the program know to keep the variable alive? --- ### ❓ Phase 4 — Reachability > How does JavaScript know to keep a variable alive? **Answer.** By *reachability*. The JavaScript engine constantly asks: "Starting from the root, which values can I reach?" Any value that can be reached is kept alive. Any value that cannot be reached is collected as garbage. **Why this matters.** Think of the engine as a janitor with a flashlight. Every few seconds, the janitor walks the whole program starting from the roots. Anything the flashlight touches stays. The rest gets thrown out. ➡️ **Next question.** If the inner function and the variable are both still alive, where do they live? On the stack or somewhere else? --- ### ❓ Phase 5 — The heap > Where do closures live in memory? **Answer.** On the *heap*, not the stack. **Why this matters.** The stack is for short-lived things tied to a function call. Closures can outlive the function that created them, so they cannot live on the stack — the stack frame is gone. Instead, the engine allocates the closure's "backpack" on the heap, where it can persist as long as something still references it. ➡️ **Next question.** If a closure can keep a variable alive forever, can that cause problems — like a program that keeps using more and more memory? --- ### ❓ Phase 6 — Memory leaks > Can closures cause memory leaks? **Answer.** Yes, if you accidentally keep a reference to a large object that should have been collected. **Why this matters.** A classic example: putting event listeners on a button inside a function that creates a closure capturing a large array. The button still has the listener. The listener still references the closure. The closure still references the array. The array never gets collected, even after the user navigates away. ➡️ **Next question.** Beyond the memory question, why are closures useful — what can you do with them that you couldn't do before? --- ### ❓ Phase 7 — Why closures matter > What are closures actually good for? **Answer.** Three things, in order of how often you'll use them: (1) *Data privacy* — a function can return another function that has access to variables nobody else can see. (2) *Partial application* — a function can return a new function with some arguments already filled in. (3) *Callbacks that remember* — a function passed to `setTimeout` or `addEventListener` can remember variables from where it was created. **Why this matters.** Closures let you carry state with behavior. A closure is a function plus the environment it was born in. That combination is what makes functional programming possible in JavaScript. --- ## 🧠 Concept Index - **Function** — A named sequence of instructions that can be invoked with different inputs and may return a value. (From Latin *functio*, "a performing, an execution.") - **Stack frame** — A region of memory created when a function is called and destroyed when it returns. Holds the function's local variables and arguments. - **Closure** — A function plus the variables it captured from where it was created. The function "closes over" the variables, carrying them with it. - **Reachability** — The rule the JavaScript engine uses to decide which values to keep alive. Any value reachable from the root stays; the rest is garbage. - **Heap** — The long-term region of memory. The stack is for short-lived function-call data; the heap is for data that may outlive the function that created it. - **Memory leak** — A value that should have been garbage-collected but isn't, because something still references it (often through a chain of closures). --- ## ✅ Final Checkpoint 1. In one sentence, what is a closure? 2. Why does the inner function's reference keep the variable alive? 3. What's the difference between the stack and the heap, in the context of closures? 4. Name two practical uses of closures. 5. How would you fix a memory leak caused by a closure? --- ## 📚 Further Paths - **Prototypal inheritance** — *Builds on Phase 1. How JavaScript objects share behavior, and why it's also based on the "function with a backpack" idea.* - **Promises and async/await** — *Builds on Phase 7. Why async functions are fundamentally a special case of "callbacks that remember."* - **Functional programming in JS** — *Builds on all phases. The big ideas of immutability, pure functions, and composition — all of which lean on closures.* --- *Generated by the Being Zetetic protocol · Driven by Mnemethos*