A closure doesn't capture the one variable you meant to use; it captures a strong reference to its entire outer lexical environment. Left unmanaged, that environment never leaves memory.
The dashboard was a complex data grid, the kind of tool an operations team keeps open all day. It worked perfectly for the first few minutes of every session. After about twenty minutes of continuous use, it started to grind filters lagged, scrolling stuttered, and eventually the whole view became sluggish enough that people started refreshing the page out of habit rather than diagnosis.
The DOM size was normal. The network requests were fine. The actual cause was an asynchronous polling loop, set up once when the component first mounted, that closed over the component's initial state. It was never cleaned up or resynchronized. Every poll cycle, it dutifully updated the UI using a reference to data that was frozen at the exact millisecond the component first rendered, and it held onto that original state object in memory for the entire session, growing more stale and more expensive with every passing minute.
The engineering team's first instinct was to blame the framework's rendering performance. The actual root cause was a fundamental property of closures that most engineers learn as a feature and never revisit as a liability: a closure does not capture the single variable you intended to use. It captures a reference to its entire enclosing lexical scope, and that scope remains pinned in memory completely immune to garbage collection for as long as the closure itself is reachable.
Closures are JavaScript's superpower. They enable encapsulation, private state, and clean module patterns that predate every modern framework. In reactive, event-driven architectures where components mount and unmount continuously and callbacks live far longer than the code that created them, that same superpower is the leading cause of stale state bugs and quiet memory bloat.
When a function is defined inside another function, it forms a closure over its enclosing scope not just the variables it references, but the entire lexical environment in which it was created. The JavaScript engine cannot selectively retain "just the parts you're using." It retains the whole environment record, because any part of it could theoretically still be accessed.
config and userSession are never referenced inside pollForUpdates, but because they exist in the same lexical scope as largeDataset, V8 cannot prove they are unreachable, and in practice engines commonly retain the whole scope record rather than performing fine-grained per-variable analysis. If pollForUpdates is registered as a setInterval callback or a long-lived event listener, every object in that outer scope remains alive for as long as the interval runs, which, if nobody explicitly clears it, is the lifetime of the page.
This is not a bug in the engine. It is the correct, specified behavior of lexical scoping. The problem is architectural: nobody decided how long pollForUpdates and everything it drags with it should actually live.
The dashboard incident above illustrates both failure modes closures produce simultaneously, because they share the same root cause.
Stale state synchronization bugs. A callback registered during an initial render captures the state variables from that specific execution context. In frameworks with reactive re-rendering, the component re-renders with fresh state on every update, but the previously registered callback does not automatically know about it. It continues operating on the closed-over values from whenever it was created.
If price updates frequently but the effect's dependency array only includes symbol, the interval closure keeps referencing the price value from whenever the effect last ran not the current one. checkAlertThreshold silently operates on old data indefinitely. This is precisely the bug that produces "it works when I test it manually but breaks after a few minutes of real use" reports, because the staleness only becomes visible once enough time has passed for the closed-over value to diverge meaningfully from the current one.
Memory bloat from pinned scope. The second, quieter cost is that everything in the captured scope stays in memory for the closure's entire lifetime. In the dashboard's case, this meant the original dataset, potentially megabytes, was never released, and the poll callback kept a live reference to it for the full session. Multiply this by every component that mounts and registers a similar long-lived callback without cleanup, and the retained memory compounds across a session that can run for hours.
The team's actual response, before finding the root cause, was to wrap the symptoms in defensive logic, extra null checks, manual re-fetch buttons, "refresh if things look wrong" instructions in the internal wiki. None of that fixes the underlying scope management problem; it just adds friction around it.
Decouple state from long-lived callbacks with a mutable reference The direct fix for the stale-price bug above is to stop relying on a closure to read a value that changes over time. In React, useRef provides a mutable container whose .current property can be read inside a stable closure without needing to recreate that closure on every render.
The interval closure still closes over priceRef, but priceRef is a stable object whose .current property is mutated in place. The closure doesn't need to be recreated every time price changes, and it always sees the current value when it actually runs. This is the standard escape hatch for reading fresh state inside a callback that must have a stable identity across renders.
Pass dynamic values as parameters instead of closing over them Where possible, the more robust fix is architectural: don't rely on closures to carry mutable values at all. Pass the value in explicitly at the moment of invocation.
The second version cannot go stale, because it has no captured state to go stale. Every call receives exactly the data it needs at the moment it needs it. This pattern is not always applicable; sometimes a stable closure identity is required by the API you are working with but it is the simplest fix whenever it is.
Explicitly break references in cleanup routines When a long-lived subscription, listener, or interval genuinely needs to hold a reference to a large object, explicitly clear that reference the moment it is no longer needed, rather than waiting for the entire closure to be discarded.