Closures and Other Great Powers of Functions in Javascript

October 14, 2011 in Web Development

Edit: I originally created this post to explain how you can use functions in Javascript and misunderstood the term “closure”. The examples are still valid and good examples of how to use functions as first-class citizens, but technically, most of them are not using “closures” – I was using the term too broadly. I got a great comment from Venkman who explained the term more accurately. Thank you Venkman

Javascript is an incredibly powerful language. There are many very interesting aspects to it, but one of it’s most useful and powerful features are it’s closures.

What are closures?

Wikipedia probably has a deeper and more accurate explanation for what a closure is, but in words that I would be able to understand:

Closures are functions that you define “on the fly” that have access to the same variables (the same scope) as they get defined in. You can store them as variables, pass them around between other functions, and generally get treated like a normal variable.

They make for some really interesting code.

Consider this example:

In this function, the logic to check if the string matches or not and the functionality of adding the string to the returned variable is defined in two places. If we were to make that more complicated or make changes, we’d have to make sure we make those changes in both places.

If we were to rewrite this example using a local closure, it would look like this:

The functionality becomes much cleaner. It’s easy to add to or modify the logic to check the string, etc.

(note that that function was only written to illustrate my point, it’s probably easy to make a better version of it that doesn’t use closures, etc.)

passing in a closure to a function

Here’s another example of how closures can be useful. Technically those are not really closures, but plain functions as variables, since they’re not taking advantage of the scope in which they are defined – but it’s a similar topic.

In this example we’ll create a function that loops through an array of strings and executes a specific callback to determine if the element should be returned.

We’re calling the function twice with the same array, but the first call will return the fruit that start with the letter “a” (apple and avocado) but the second one will return all the fruit whose name is more than 5 letters in length.

Again, a simple example but illustrative of the powerful stuff that can be achieved using closures.

Returning closures as variables

Closure become even more interesting when you think of a function that actually returns a closure. Here’s an example:

This function does nothing but return another function. However that function gets called within the scope of the function that created it, which allows us to pass in a variable, which that function has access to.

That means that if you look at the last two statements, they are comparing the “other string” and “some string” to the string previously used when calling the function that created the closure.

That allows us to compare the string easily without passing in the first string again and again. This example is a bit of a brain-bender, but it’s probably worth it to dwell on the concept for a few seconds.

The example doesn’t have much use, but it is the most clean example I could think of to illustrate the point.

Here’s another example that might be a bit more useful or have more real-world application:

There are probably a lot of jQuery users out there, so this might make more sense as a real-world example.

Now the function-producing function accepts a selector as an argument. That means we can pass in any jQuery selector and it will return a function that tells us if a particular jQuery object matches the selector.

Again, it’s probably too much of an over-kill for such a simple example, but it’s easy to imagine extending this to accept an array of selectors or some other type of condition, eg. traversing through the parents to find something out about them, and then being able to call that with a given array of selectors.


Thinking about code in closures is a very different beast than typical object oriented programming. They are in fact the pillar of functional programming and provide very unique brain-twisting ways to code.

They can easily be misused and there are certainly all kinds of ways where they just make things more complicated. Your scope can soon get out of control and it gets hard to read other people’s code, but if used right they make allow us to simply have less code. Which is probably what we generally strive for.

Let me know if you have anything more to add or additional examples that you think could be useful.

  • venkman


    Please, be aware that what you’re calling closures in some cases aren’t really.

    E.g. in example2.js there is no closure. It’s just a local function. In example5.js you’re simply passing some anonymous functions as parameters to the all_elements_match function, but again those are not closures. It’s only in the last 2 snippets (example3.js and example4.js) that you’re actually creating closures.

    The problem is that in your definition an important detail is missing. The function in the closure does have access to the scope it was defined in… *but that scope is closed when the function is actually executed*.

    This is an important detail. Let’s take example2.js. The cl function has access to the collection. Sure. But so does everything else when cl is executed. I mean, in the line where you call cl(myvar[i]); you could just as well do if (myvar[i] != str) { collection.push(myvar[i]); } with no difference at all. You have access to all variables involved.

    What distinguishes this from, say, example3.js, is that in example3.js when you call b(“other string”); you couldn’t do “other string” === a because in that line you do not have access to a. a was only in scope when b was created (b = ret(“some string”)), but afterwards that scope is /closed/. b has access to that closed scope, but the rest of the world doesn’t.

    • arnorhs

      That’s a very good point. I’m probably using the term “closure” too broadly in this post. I guess the post could also have been called “functions as first class citizens in javascript” and the functions not referred to as closures.

      Not sure what to call them then. Maybe just “functions” or “inline functions” — the ability to name the pattern of using functions in this way should probably have a name (and it probably does, which I am unaware of) — maybe “functional programming” is the most accurate term.

      Sometimes having a term to group ideas by so they’re easily consumable makes it easier to consume. Maybe we need a stronger name for that concept. Something lame like “power function” could possibly be made, but I digress.

      Thanks for your comment. It’s helpful to me and probably is also to other people.

  • Pingback: Elegant D » Closures in Javascript by @arnorhs