Not to be a hater, but the examples on the blog post are insane. Why would I write code like any of those? To try to put a name on what you've observed, what y

Not to be a hater, but the examples on the blog post are insane. Why would I write code like any of those? To try to put a name on what you've observed, what you're really doing is emulating a call-by-name [1] evaluation strategy, in which you want an expression to be evaluated at the time the asynchronous callee needs the value, rather than when the call is scheduled. Some languages (like Scala) have specific syntax for this, but in other languages, you emulate this behavior by wrapping the expression in a function, and calling that function when you want the expression to be evaluated. The closure facilitates this by letting you bind names in the expression to variables in the outer scope. These variables aren't available to the actual caller of the function (somewhere in setTimeout's implementation) to be bound to the function's arguments in the "normal" way. So really, you find that there are two basic ways to make variables available to a function's scope: the invoker of the function can bind the function's arguments to values in its scope, or the function can bind variables from any of the scopes that enclose it, namely all of the enclosing functions. (There's also `this`, but that's another story.) A much better use case is if you want an event handler to have access to the state of the object that registered it. If you bind the event handler within that object's scope, you can refer to that state within the event handler, and whenever it fires, the current value of state will available from the enclosing scope. This comes up all the time for me when writing Backbone apps. When doing this kind of stuff, be sure to understand thoroughly how Javascript's `this` works (ugh...). Also, when designing recursive algorithms, closures give the innermost nested layers of your algorithm access to variables from outer scopes, reducing the need to awkwardly pass in parameters that don't change between inner function invocations. Closures are just the tip of the iceberg. Other concepts like higher-order functions, decorators, and combinators are also really powerful. I highly recommend the most excellent Javascript Allongé [2] for anyone who truly wants to understand this stuff, and learn how to really make it work for them. [1] http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_name http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_nam... [2] https://leanpub.com/javascript-allonge/read https://leanpub.com/javascript-allonge/read