Where Do Closures Earn Their Keep?

Closures are useful whenever you want a function to remember something without that something being visible to the rest of the program. Six patterns come up constantly.

Private state. A factory function keeps a variable in its own scope and hands back only the functions you are willing to expose. Nothing outside can read or change the state, and there is no way to bypass the checks you put in front of it.

Memoisation. A function that caches its results in a closure only does the expensive work once. The cache is private, so it cannot be corrupted from outside, and it is discarded when nothing holds the function any more.

Event handlers and callbacks. A handler needs to know which row, which item or which request it belongs to, and a closure is how you give it that context without inventing a global.

Module factories. A function that takes a configuration and returns a configured object is a closure, which is how you build testable, reusable modules.

Middleware and decorators. A wrapper function takes a function and returns a function that adds behaviour around it, and the added behaviour usually needs state of its own.

Currying and partial application. A function that takes some arguments and returns a function waiting for the rest is a closure over the arguments it already has.

The honest caveat is that closures are everywhere in JavaScript whether you notice them or not, so it is better to think of them as a tool than as a feature to use deliberately. The question is always whether the state you are keeping alive is worth keeping alive.

The example below builds an object with a secret that cannot be read or changed from outside. The only way to interact with it is through the methods the factory chose to expose.

// A closure that remembers a key without exposing it.
const createSecretBox = (secret) => {
  let opened = false;

  return {
    open(attempt) {
      if (attempt === secret) {
        opened = true;
        return "unlocked";
      }
      return "denied";
    },
    isOpen: () => opened,
  };
};

const box = createSecretBox("s3cret");
console.log(box.open("wrong"));    // "denied"
console.log(box.open("s3cret"));   // "unlocked"
console.log(box.isOpen());         // true

The secret value and the opened flag both live in the scope of the factory call. They are not properties of the returned object, so they cannot be reached from outside, and they are not reachable through the inspector either. The only route in is the open method, and it enforces the rule that the secret has to match.

That is the real value of the pattern. Compare it with the obvious alternative, where the secret is a property on the object. There, anything holding the object can read the property and change it, and nothing stops a caller from setting the flag directly. With the closure, the invariants are enforced by construction rather than by convention.

Two practical notes. The comparison here is a plain equality check, which is fine for a demonstration but is not how you would compare a real secret. And a closure keeps its captured values alive for as long as the returned object is reachable, so this pattern is not free in memory terms if you capture something large.