The secret lives of JavaScript closures
Tags: javascript
Published: 2020-09-10 19:43:57

---
title: The secret lives of JavaScript closures
published: true
description: A deep dive into the world of JavaScript closures
tags: javascript
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/unvxxlkiol314rs46lwj.jpg
---

> <b>Cover photo by [Joan Garnell](https://unsplash.com/@gamell) on [Unsplash](https://unsplash.com/).</b>

## __Introduction__

Closures date back to the 1960s, long before most modern programming languages and they've turned out to be quite an essential concept in solving some programming challenges. The name of the concept itself should give you an idea that to some extent it's about "closing" something up.

In this article we'll discuss closures in JavaScript, how they work, use case, advantages, and disadvantages. First, we'll begin with the general concept of closures in programming and its origin.

## __Table of Contents__

* [General concept of closures](#general-concept)
  * [Scope](#scope)
  * [Name binding](#name-binding)
  * [First-class functions](#first-class-functions)
* [Origin of closures](#origin-of-closures)
* [Closures in JavaScript](#closures-in-javascript)
  * [Lexical Environment](#lexical-environment)
  * [Free variable](#free-variable)
  * [Funarg problem](#funarg-problem)
  * [Execution context](#execution-context)
  * [Scope chain](#scope-chain)
* [Uses of JavaScript closures](#uses-of-javascript-closures)
  * [Binding Event Handlers](#binding-event-handlers)
  * [Private Instance Variables](#private-instance-variables)
  * [Data Encapsulation](#data-encapsulation)
  * [Functional Programming](#functional-programming)
  * [Modularization](#modularization)
* [Advantages of closures](#advantages-of-closures)
* [Disadvantages of closures](#disadvantages-of-closures)
* [Conclusion](#conclusion)
* [References](#references)

## __General concept of closures <a name="general-concept"></a>__

[Wikipedia defines closures](https://en.wikipedia.org/wiki/Closure_(computer_programming)) quite well and it goes thus:

> In programming languages, a closure, also lexical closure or function closure, is a technique for implementing lexically scoped name binding in a language with first-class functions.

This definition details what closure is all about which is: _lexically scoped_ _name binding_ and _first-class functions_.

### __Scope <a name="scope"></a>__

In programming, _scope_ is a region where a name binding is valid.

### __Name binding <a name="name-binding"></a>__

This is the association of entities with identifiers.

### __First-class functions <a name="first-class-functions"></a>__

These are functions that are passed as arguments to other functions, they can be assigned to a variable and they can be returned as the value of another function.

## __Origin of closures <a name="origin-of-closures"></a>__

As noted at the beginning of this article, closures dates back to the 1960s, once again [Wikipedia](https://en.wikipedia.org/wiki/Closure_(computer_programming)#History_and_etymology) got us covered:

> The concept of closures was developed in the 1960s for the mechanical evaluation of expressions in the λ-calculus and was first fully implemented in 1970 as a language feature in the PAL programming language to support lexically scoped first-class functions.

> Peter J. Landin defined the term closure in 1964 as having an environment part and a control part as used by his SECD machine for evaluating expressions. Joel Moses credits Landin with introducing the term closure to refer to a lambda expression whose open bindings (free variables) have been closed by (or bound in) the lexical environment, resulting in a closed expression, or closure. This usage was subsequently adopted by Sussman and Steele when they defined Scheme in 1975 a lexically scoped variant of LISP, and became widespread.

In the quote above, you'll note the following:

* First-class functions
* Lexical Environment
* Free variables

Except for _first-class functions_ (discussed earlier), we'll discuss the concept behind _lexical environment_ and _free variables_ later in the article.

In addition to the history from Wikipedia, [Dmitry Soshnikov](https;//twitter.com/dmitrysoshnikov) has this to say:

{% twitter 1283095653015449600 %}

What this tweet entails is our next talking point.

## __Closures in JavaScript <a name="closures-in-javascript"></a>__

At the onset of programming with JavaScript, the concept of closures _might_ be a difficult thing to grasp, reality is, if you've written JavaScript code before you might have used (or created) a closure without realizing it.

Take the following code example:

 ```js
let myName = "Habdul";

function getmyName() {
    let lastName = "Hazeez";
    console.log(myName + " " + lastName);
}

getmyName(); // Habdul Hazeez
 ```

When the function `getmyName()` is called the output is `Habdul Hazeez`. Why is this?

You might not know it but this is a basic example of a _closure_. The function `getmyName()` was  defined with an internal variable `lastName` and we appended its value with the value of the variable `myName` defined outside the function which led to the output `Habdul Hazeez` when the function is invoked.

Another question is: Why did function `getmyName` have access to `myName` variable? The answer is simple _lexical environment_.

### __Lexical Environment <a name="lexical-environment"></a>__

From [Stack Overflow](https://stackoverflow.com/questions/12599965/lexical-environment-and-function-scope/50174232#50174232):

> Lexical Environment: it's the internal JavaScript engine construct that holds identifier-variable mapping (here identifier refers to the name of the variables/functions,and variable is the reference to actual object [including function type object] or primitive value).

> A lexical environment holds a __reference to a parent lexical environment__.

And also from [Stack Overflow](https://stackoverflow.com/questions/111102/how-do-javascript-closures-work/111111#111111):

> Every function in JavaScript maintains a reference to its outer  lexical environment. This reference is used to configure the execution  context created when a function is invoked. __This reference enables code  inside the function to "see" variables declared outside the function__,  regardless of when and where the function is called.

Now we know why function `getmyName` had access to the `myName` variable. It's because function `getmyName` had a reference to its parent lexical environment and this reference enabled it to see the variables declared in this parent lexical environment or we can say this reference enabled the code inside the function to _see_  variables declared outside the function.

In this context the parent lexical environment of function `getmyName` is the _global object_ and the variable `myName` is known as a _free variable_.

### __Free variable <a name="free-variable"></a>__

A free variable is a variable which is *neither a parameter*, *nor a local variable* of this function.

Let's take a look at another example:

```js
let myName = "Habdul Hazeez";

function logmyName() {
    console.log(myName);
}

function getmyName(funArg) {
    let myName = "Jonathan Sanchez";
    funArg();
}

getmyName(logmyName); // ?
```

What will be the output of `getmyName()` and why? Let's take a step backwards and analyze what is going on.

From the code snippet you'll notice the following:

1. Free variable is in use (`myName`).
2. Function `logmyName` is passed as an argument to function `getmyName`.

In JavaScript functions are _first class citizens_ which means we can assign them to a variable, return them from a function, and pass them as an argument to another function. 

Therefore, when we call the function `getmyName` as thus: `getmyName(logmyName)` which of the `myName` variable should it use? The one with the `Habdul Hazeez` or the one with `Jonathan Sanchez`?

This leads to a problem known as _funarg problem_.

### __Funarg problem <a name="funarg-problem"></a>__

The _funarg problem_ occurs when a programming language treats functions as _first class functions_ which has to deal with _free variables_.

The _funarg problem_ is further divided into two sub-type:

1. _downward funarg problem_
2. _upward funarg problem_

We just saw the _downward funarg problem_ in action when a _free variable_ was declared before a function that ends up using it.

Dmitry Soshnikov [defines the _downward funarg_](http://dmitrysoshnikov.com/ecmascript/javascript-the-core-2nd-edition/#closure) as:

> an *ambiguity* at determining a *correct environment* of a binding: should it be an environment of the *creation time*, or environment of the *call time*?

Loosely meaning:

> When a function wants to use a variable, should it use the one present at the time it was created or the variable at the time it was called (as demonstrated by our example)?.

In order to resolve this problem the function will use the variable declared at its time of creation not at the point of its invocation therefore, the function `logmyName` will use the variable `myName` declared where it was created which has the value `Habdul Hazeez`.

The _upward funarg problem_ is illustrated in the following code snippet:

```js
function details() {
    let myName = "Habdul Hazeez";
    
    // Closure, capturing environment of `details`.
    function getmyName() {
        return myName;
    }
    
    return getmyName;
    
}

let myDetails = details();

myDetails(); // Habdul Hazeez
```

The function `details` consists of a local variable `myName` and a function `getmyName`. The function `getmyName` consists of a single statement which  returns the `myName` variable. At this point it is said that we have captured the `myName` variable in a closure and we will be able to access it after the function completes its execution.

Later in the code we assigned the `details` function to `myDetails` variable and we invoke it as function. All this happened after the function declaration. This is the _upward funarg problem_ where the capturing environment (`getmyName`) outlives the _context_ which creates it (`details`).

### __Execution Context <a name="execution-context"></a>__

In _layman_ terms,  execution context is the environment where your code is executed.

Technically, it's more than that and the term "execution context" is a source of confusion because it's not really about a "context" but about _scope_.

An execution context is created every time a function is invoked, it's composed of the activation object (the function's parameters and local variables), a reference to the _scope chain_, and the value of `this`.

```js
// Global context

function one() {
    // "one" execution context
    
    function two() {
        
        // "two" execution context
        
    }
    
    function three() {
        
        // "three" execution context
        
    }
    
}
```

Every execution context created is added to the top of the execution stack. The web browser will execute the current execution context that is found at the top of the execution stack. Once completed, it will be removed from the top of the stack and control will return to the execution context below.

Once removed, everything about the function that created the execution is destroyed, but we can preserve this state when we return an inner function which has access to the local variables, arguments, and inner function declarations of its outer function. This outer function is the parent lexical environment and the inner function is a _closure_.

```js
function getMyName() {
    let myName = "Habdul Hazeez";
    
    // inner function
    return function() {
        return myName;
    }
    
}

let whatIsMyName = getMyName();
whatIsMyName(); // Habdul Hazeez.
```

The variable `myName` is a free variable and for the inner function to search for it (before using it, in this case it simply returns it) a _scope chain_ is used.

### __Scope chain <a name="scope-chain"></a>__

A *scope chain* is a list of objects that are searched for *identifiers* which appear in the code of the context. In general case, a *scope chain* is a list of all those *parent variable objects*, *plus* (in the front of scope chain) the function’s *own variable/activation object* ([source](http://dmitrysoshnikov.com/ecmascript/javascript-the-core/#scope-chain)).

From previous paragraphs we know about an activation object. But what is a _variable object_?

Once again, Dmitry to the rescue. [He defined a variable object as thus](http://dmitrysoshnikov.com/ecmascript/javascript-the-core/#variable-object):

> A *variable object* is a *container of data* associated with the execution context. It’s a special object that stores *variables* and *function declarations* defined in the context.

Therefore, when the anonymous function could not find the variable `myName` as part of its local variables it used the _scope chain_ to search for it and the variable was found in its parent variable object created for the function `getMyName`.

The scope chain is also used when we have deep nested function as shown in the example below.

```js
function first() {
    second();
    function second() {
        third();
        function third() {
            fourth();
            function fourth() {
                // code here
            }
        }
    }   
}

first();
```

The `fourth` function would have access to global variables and any variables defined within the three preceding functions.

Simply put, each time you attempt to access a variable within a function’s execution context, the look-up process will always begin with its own variable object. If the identifier is not found in the variable object, the  search continues into the _scope chain_. It will climb up the scope chain  examining the _variable object_ of every execution context looking for a  match to the variable name ([source](http://ryanmorr.com/understanding-scope-and-context-in-javascript/)).

_In ES5 the concepts of *variable object*, and *activation object* are combined into the *lexical environments* model discussed earlier._

## __Uses of JavaScript closures <a name="uses-of-javascript-closures"></a>__

As stated at the beginning of this article, closures do solve some programming challenges. It's impossible and impractical to cover them all, instead we'll discuss some situations that closures are really useful.

In no particular order they are:

* Binding Event Handlers
* Private Instance Variables
* Data Encapsulation
* Functional Programming
* Modularization

### __Binding Event Handlers <a name="binding-event-handlers"></a>__

Events occur as a result of user interaction with the application interface e.g. mouse clicks and key press.

JavaScript is used to handle events on a Web page and there are numerous ways to track events on a Web page.

Let's take a hypothetical example that we'll like to know which button was clicked on a Web page so that we can perform further actions after the _click_ event.

```html
<button>Click me</button>
<button>Click me1</button>
<button>Click me2</button>
```

Our first approach can go as thus:

1. Select all button on the Web page.
2. Loop through the result then attach an event listener to each button.

```js
var myElements = document.getElementsByTagName('button');

for (var i = 0; i < myElements.length; i++) {
    myElements[i].onclick = function() {
        alert( 'You clicked on: ' + i );
    };
}
```

_Note: We declared our variable using the `var` keyword just so we can see how closure was used to solve this kind of issue pre-ES6_.

When each button is clicked, the result for `i` is `3` which is unexpected because `3` is the last assigned value to `i`. This problem can be solved using _closure_.

```js
function getButton(n) {
    return function() {
        alert( 'You clicked on: ' + n );
    };
}

for (var i = 0; i < myElements.length; ++i) {
    myElements[i].onclick = getButton(i);
}
```

The key to understanding the modified code is that every time `getButton` is called, a new closure is produced, and each of these closures has a different `i`.

Now, when the buttons are clicked everything works as expected.

> NOTE: In ES6 the code be rewritten as:
>
> ```js
> let myElements = document.getElementsByTagName('button');
> 
> for (let i = 0; i < myElements.length; ++i) {
>     myElements[i].onclick = function() {
>         alert( 'You clicked on: ' + i );
>     }
> }
> ```

### __Private Instance Variables <a name="private-instance-variables"></a>__

Functions in JavaScript can have variables declared as _formal parameters_ and these parameters can be returned using the `return` keyword.

When this function is used for creating objects with the `new` keyword, these variables are termed _instance variables_ in this newly created object.

Let's take an example that you have the following code:

```js
function Developer(first_name, speciality, age) {
 
   return `${first_name} ${speciality} ${age}`
    
}
```

The variables can be modified easily leading to undesired results.

```js
// Modify the variable
Developer.first_name = "John";
```

Now, let's construct an object from this  function.

```js
let newDeveloper = new Developer('Ben', 'Webmaster', '100');
```

When we check the details of `newDeveloper` we get an empty object due to the variable that we modified earlier.

```js
newDeveloper;
// Object {  }
```

When this object is expanded in the browser developer tools we get the following:

```
{}
<prototype>: {…}
    constructor: Developer(first_name, speciality, age)
        arguments: null
        caller: null
        first_name: "John"
        length: 3
        name: "Developer"
    prototype: {…}
    <prototype>: function ()
    <prototype>: Object { … }
```

It's evident we've modified the variable `first_name`.

What if we can prevent this happening? That's when we can use _private instance variables_. In reality, JavaScript has no concept of "private variables" but we can simulate it with the use of _closures_.

Still using our example, we'll modify it by adding a method that will have access to the function variables, and it will prevent modification from external actors.

 ```js
function Developer(first_name, speciality, age) {
    return {
        devDetails() {
            return `${first_name} ${speciality} ${age}`
        }
    }
}
 ```

Let's repeat the steps we performed earlier.

```js
// Try and modify the first_name variable
Developer.first_name = "Habdul";
```

Construct an object from the function:

```js
let john = new Developer('John', 'System engineer', '34');
```

Moving forward, we check the developer details by invoking the `devDetails` function and it will work as expected.

```js
john.devDetails(); // "John System engineer 34
```

This was not the case when the variables were free for modification causing issues along the way. You can type the variable name `john`  in the browser developer tools and expanding the output. It should be different compared to when we modified the `first_name` variable.

### __Data Encapsulation <a name="data-encapsulation"></a>__

Encapsulation is the process of exposing what another part of a program can access when they are divided into smaller components whereby some components are public and others are private. This includes the following:

* Variable names
* Functions
* Methods (functions in an object)

In JavaScript, encapsulation can be achieved using closures as seen in the following [example from CSS-Tricks](https://css-tricks.com/implementing-private-variables-in-javascript/).

```js
const CarModule = () => {
    let milesDriven = 0;
    let speed = 0;
    
    const accelerate = (amount) => {
        speed += amount;
        milesDriven += speed;
    }
    
    const getMilesDriven = () => milesDriven;
    
    // Using the "return" keyword, you can control what gets
    // exposed and what gets hidden. In this case, we expose
    // only the accelerate() and getMilesDriven() function.
    return {
        accelerate,
        getMilesDriven
    }
};
```

### __Functional Programming <a name="functional-programming"></a>__

Functional programming is mostly about functions. And we already know that closures can be a normal function in JavaScript or an inner function meaning we've done a bit of "functional programming" in this article. Well, let's talk about the relationship between FP (functional programming) and closures.

In the example illustrated below we'll like to add two numbers using _currying_.

Currying has its roots in mathematics and computer science and it's the technique of converting a function that takes multiple arguments into a sequence of functions that each take a single argument ([source](https://en.wikipedia.org/wiki/Currying)).

```js
function add(a) {
    
    // The anonymous function closes over the
    // variables a and b
    return function(b) {
        return a + b;
    }
    
}

add(1)(2); //3
```

The function `add` takes just a single argument but it returns another function (the closure) which takes another argument and in-turn returns the result of the addition.

### __Modularization <a name="modularization"></a>__

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent,  interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality ([source](https://en.wikipedia.org/wiki/Modular_programming)).

This involves grouping some lines of code into a unit that can be included in the program. Can you guess the name of this type of unit? Functions. These functions can in-turn contain another function. You see where I am going? Bottom line; closures. Which we already learned it can be a single function or a function inside another function.

An example of writing modular JavaScript code is the following example from [Stack Overflow](https://stackoverflow.com/questions/111102/how-do-javascript-closures-work/111111#111111).

```js
let namespace = {};

// All implementation details are in an Immediately
// Invoked Function Expression (IIFE)
(function foo(n) {
    
    let numbers = []
    
    function format(n) {
        return Math.trunc(n)
    }
    
    // Capture the numbers variable in a closure
    function tick() {
        numbers.push(Math.random() * 100)
    }
    
    // Capture the format function in a closure
    function toString() {
        return numbers.map(format)
    }
    
    // Expose the tick and toString function
    // to the public
    n.counter = {
        tick,
        toString
    }
    
}(namespace))

// Assign the public methods to a variable
const counter = namespace.counter;

/**
 * Invoke the tick function twice which automatically pushes
 * a random number into the private variable
 * numbers.
 */
counter.tick();
counter.tick();

// Invoke the toString method
console.log(counter.toString()); // Example output: Array [ 42, 46 ]
```

It's evident that the function `tick` and `toString` capture the state of the variable (`numbers`) and function (`format`).

## __Advantages of closures <a name="advantages-of-closures"></a>__

_The uses we've discussed so far_. 

## __Disadvantages of closures <a name="disadvantages-of-closures"></a>__

Closures are useful, but they also have their disadvantages. They are:

* As long as closures are active, this memory cannot be garbage collected.
* Creating functions inside other functions lead to duplication in memory, potentially slowing down the application.

## __Conclusion <a name="conclusion"></a>__

In this article we've talked about JavaScript closures, but we did not cover some of its deep technical details therefore, I'll encourage you to have a look at additional literature's in the _references_.

## __References <a name="references"></a>__

* [Closure on Wikipedia](https://en.wikipedia.org/wiki/Closure_(computer_programming))
* [History of Closure](https://en.wikipedia.org/wiki/Closure_(computer_programming)#History_and_etymology)
* [How do JavaScript closures work?]([How do JavaScript closures work?](https://stackoverflow.com/questions/111102/how-do-javascript-closures-work))
* [Implementing Private Variables In JavaScript ](https://css-tricks.com/implementing-private-variables-in-javascript/)
* [JavaScript. The Core.](http://dmitrysoshnikov.com/ecmascript/javascript-the-core/)
* [JavaScript. The Core: 2nd Edition](http://dmitrysoshnikov.com/ecmascript/javascript-the-core-2nd-edition/)
* [ECMA-262-3 in detail. Chapter 4. Scope chain.](http://dmitrysoshnikov.com/ecmascript/chapter-4-scope-chain/#definition)
* [ECMA-262-3 in detail. Chapter 6. Closures.](http://dmitrysoshnikov.com/ecmascript/chapter-6-closures/)
* [Modular Programming by Kenneth Leroy Busbee and Dave Braunschweig](https://press.rebus.community/programmingfundamentals/chapter/modular-programming/)
* [JavaScript closure advantages?](https://stackoverflow.com/questions/6309947/javascript-closure-advantages)
* [Understanding Scope and Context in JavaScript](http://ryanmorr.com/understanding-scope-and-context-in-javascript/)
* [What is the 'Execution Context' in JavaScript exactly?](https://stackoverflow.com/questions/9384758/what-is-the-execution-context-in-javascript-exactly)
* [Using JavaScript closures in setTimeout](https://stackoverflow.com/questions/7721200/using-javascript-closures-in-settimeout)
* [What is the Execution Context & Stack in JavaScript?](https://web.archive.org/web/20200226035137/http://davidshariff.com/blog/what-is-the-execution-context-in-javascript/)

_Updated September 11, 2020: Grammar fix._