Scope, or the set of rules that determine where your variables live, is one of the most basic concepts of any programming language. It's so fundamental, in fact, that it's easy to forget how subtle the rules can be!

Understanding exactly how the JavaScript engine "thinks" about scope will keep you from writing the common bugs that hoisting can cause, prepare you to wrap your head around closures, and get you that much closer to never writing bugs ever again.

... Well, it'll help you understand hoisting and closures, anyway. 

In this article, we'll take a look at:

• the basics of scopes in JavaScript
• how the interpreter decides what variables belong to what scope
• how hoisting really works
• how the ES6 keywords let and const change the game

Let's dive in.

Lexical Scope

If you've written even a line of JavaScript before, you'll know that where you define your variables determines where you can use them. The fact that a variable's visibility depends on the structure of your source code is called lexical scope.

There are three ways to create scope in JavaScript:

1. Create a function. Variables declared inside functions are visible only inside that function, including in nested functions.
2. Declare variables with let or const inside a code block. Such declarations are only visible inside the block.
3. Create a catch block. Believe it or not, this actually does create a new scope!

"use strict";
var mr_global = "Mr Global";

function foo () {
    var mrs_local = "Mrs Local";
    console.log("I can see " + mr_global + " and " + mrs_local + ".");

    function bar () {
        console.log("I can also see " + mr_global + " and " + mrs_local + ".");
    }
}

foo(); // Works as expected

try {
    console.log("But /I/ can't see " + mrs_local + ".");
} catch (err) {
    console.log("You just got a " + err + ".");
}

{
    let foo = "foo";
    const bar = "bar";
    console.log("I can use " + foo + bar + " in its block...");
}

try {
    console.log("But not outside of it.");
} catch (err) {
    console.log("You just got another " + err + ".");
}

// Throws ReferenceError!
console.log("Note that " + err + " doesn't exist outside of 'catch'!") 

The snippet above demonstrates all three scope mechanisms. You can run it in Node or Firefox, but Chrome doesn't play nice with let, yet.

We'll talk about each of these in exquisite detail. Let's start with a detailed look at how JavaScript figures out what variables belong to what scope.

The Compilation Process: A Bird's Eye View

When you run a piece of JavaScript, two things happen to make it work.

1. First, your source gets compiled.
2. Then, the compiled code gets executed.

During the compilation step, the JavaScript engine:

1. takes note of all of your variable names
2. registers them in the appropriate scope
3. reserves space for their values

It's only during execution that the JavaScript engine actually sets the value of variable references equal to their assignment values. Until then, they're undefined. 

Step 1: Compilation

// I can use first_name anywhere in this program
var first_name = "Peleke";

function popup (first_name) {
    // I can only use last_name inside of this function
    var last_name = "Sengstacke";
    alert(first_name + ' ' + last_name);
}

popup(first_name);

Let's step through what the compiler does.

First, it reads the line var first_name = "Peleke". Next, it determines what scope to save the variable to. Because we're at the top level of the script, it realizes we're in the global scope. Then, it saves the variable first_name to the global scope and initializes its value to undefined.

Second, the compiler reads the line with function popup (first_name). Because the function keyword is the first thing on the line, it creates a new scope for the function, registers the function's definition to the global scope, and peeks inside to find variable declarations.

Sure enough, the compiler finds one. Since we have var last_name = "Sengstacke" in the first line of our function, the compiler saves the variable last_name to the scope of popup—not to the global scope—and sets its value to undefined. 

Since there are no more variable declarations inside the function, the compiler steps back into the global scope. And since there are no more variable declarations there, this phase is done.

Note that we haven't actually run anything yet. The compiler's job at this point is just to make sure it knows everyone's name; it doesn't care what they do. 

At this point, our program knows that:

1. There's a variable called first_name in the global scope.
2. There's a function called popup in the global scope.
3. There's a variable called last_name in the scope of popup.
4. The values of both first_name and last_name are undefined.

It doesn't care that we've assigned those variables values elsewhere in our code. The engine takes care of that in execution.

Step 2: Execution

During the next step, the engine reads our code again, but this time, executes it. 

First, it reads the line, var first_name = "Peleke". To do this, the engine looks up the variable called first_name. Since the compiler has already registered a variable by that name, the engine finds it, and sets its value to "Peleke".

Next, it reads the line, function popup (first_name). Since we're not executing the function here, the engine isn't interested and skips on over it.

Finally, it reads the line popup(first_name). Since we are executing a function here, the engine:

1. looks up the value of popup
2. looks up the value of first_name
3. executes popup as a function, passing the value of first_name as a parameter

When it executes popup, it goes through this same process, but this time inside the function popup. It:

1. looks up the variable named last_name
2. sets last_name's value equal to "Sengstacke"
3. looks up alert, executing it as a function with "Peleke Sengstacke" as its parameter

Turns out there's a lot more going on under the hood than we might have thought!

Now that you understand how JavaScript reads and runs the code you write, we're ready to tackle something a little closer to home: how hoisting works.

Hoisting Under the Microscope

Let's start with some code.

bar();

function bar () {
    if (!foo) {
        alert(foo + "? This is strange...");
    }
    var foo = "bar";
}

broken(); // TypeError!
var broken = function () {
    alert("This alert won't show up!");
}

If you run this code, you'll notice three things:

1. You can refer to foo before you assign to it, but its value is undefined.
2. You can call broken before you define it, but you'll get a TypeError.
3. You can call bar before you define it, and it works as desired.

Hoisting refers to the fact that JavaScript makes all of our declared variable names available everywhere in their scopes—including before we assign to them.

The three cases in the snippet are the three you'll need to be aware of in your own code, so we'll step through each of them one by one.

Hoisting Variable Declarations

Remember, when the JavaScript compiler reads a line like var foo = "bar", it:

1. registers the name foo to the nearest scope
2. sets the value of foo to undefined

The reason we can use foo before we assign to it is because, when the engine looks up the variable with that name, it does exist. This is why it doesn't throw a ReferenceError. 

Instead, it gets the value undefined, and tries to use that to do whatever you asked of it. Usually, that's a bug.

Keeping that in mind, we might imagine that what JavaScript sees in our function bar is more like this:

function bar () {
    var foo; // undefined
    if (!foo) {
        // !undefined is true, so alert
        alert(foo + "? This is strange...");
    }
    foo = "bar";
}

This is the First Rule of Hoisting, if you will: Variables are available throughout their scope, but have the value undefined until your code assigns to them.

A common JavaScript idiom is to write all of your var declarations at the top of their scope, instead of where you first use them. To paraphrase Doug Crockford, this helps your code read more like it runs.

When you think about it, that makes sense. It's pretty clear why bar behaves the way that it does when we write our code the way JavaScript reads it, isn't it? So why not just write like that all the time?  

Hoisting Function Expressions

The fact that we got a TypeError when we tried to execute broken before we defined it is just a special case of the First Rule of Hoisting.

We defined a variable, called broken, which the compiler registers in the global scope and sets equal to undefined. When we try to run it, the engine looks up the value of broken, finds that it's undefined, and tries to execute undefined as a function.

Obviously, undefined isn't a function—that's why we get a TypeError!

Hoisting Function Declarations

Finally, recall that we were able to call bar before we defined it. This is due to the Second Rule of Hoisting: When the JavaScript compiler finds a function declaration, it makes both its name and definition available at the top of its scope. Rewriting our code yet again:

function bar () {
    if (!foo) {
        alert(foo + "? This is strange...");
    }
    var foo = "bar";
}

var broken; // undefined

bar(); // bar is already defined, executes fine

broken(); // Can't execute undefined!

broken = function () {
    alert("This alert won't show up!");
}

 Again, it makes much more sense when you write as JavaScript reads, don't you think?

To review:

1. The names of both variable declarations and function expressions are available throughout their scope, but their values are undefined until assignment.
2. The names and definitions of function declarations are available throughout their scope, even before their definitions.

Now let's take a look at two new tools that work a bit differently: let and const.

let, const, & the Temporal Dead Zone

Unlike var declarations, variables declared with let and const don't get hoisted by the compiler.

At least, not exactly. 

Remember how we were able to call broken, but got a TypeError because we tried to execute undefined? If we'd defined broken with let, we'd have gotten a ReferenceError, instead:

"use strict";
// You have to "use strict" to try this in Node
broken(); // ReferenceError!
let broken = function () {
    alert("This alert won't show up!");
}

When the JavaScript compiler registers variables to their scopes in its first pass, it treats let and const differently than it does var. 

When it finds a var declaration, we register the name of the variable to its scope and immediately initialize its value to undefined.

With let, however, the compiler does register the variable to its scope, but does not initialize its value to undefined. Instead, it leaves the variable uninitialized, until the engine executes your assignment statement. Accessing the value of an uninitialized variable throws a ReferenceError, which explains why the snippet above throws when we run it.

The space between the beginning of top of the scope of a let declaration and the assignment statement is called the Temporal Dead Zone. The name comes from the fact that, even though the engine knows about a variable called foo at the top of the scope of bar, the variable is "dead", because it doesn't have a value.

... Also because it'll kill your program if you try to use it early.

The const keyword works the same way as let, with two key differences:

1. You must assign a value when you declare with const.
2. You cannot reassign values to a variable declared with const.

This guarantees that const will always have the value that you initially assigned to it.

// This is legal
const React = require('react');

// This is totally not legal
const crypto;
crypto = require('crypto');

Block Scope

let and const are different from var in one other way: the size of their scopes.

When you declare a variable with var, it's visible as high up on the scope chain as possible—typically, at the top of the nearest function declaration, or in the global scope, if you declare it in the top level. 

When you declare a variable with let or const, however, it's visible as locally as possible—only within the nearest block.

A block is a section of code set off by curly braces, as you see with if/else blocks, for loops, and in explicitly "blocked" chunks of code, like in this snippet.

"use strict";

{
  let foo = "foo";
  if (foo) {
      const bar = "bar";
      var foobar = foo + bar;

      console.log("I can see " + bar + " in this bloc.");
  }

  try {
    console.log("I can see " + foo + " in this block, but not " + bar + ".");
  } catch (err) {
    console.log("You got a " + err + ".");
  }
}

try {
  console.log( foo + bar ); // Throws because of 'foo', but both are undefined
} catch (err) {
  console.log( "You just got a " + err + ".");
}

console.log( foobar ); // Works fine

If you declare a variable with const or let inside a block, it's only visible inside the block, and only after you've assigned it.

A variable declared with var, however, is visible as far away as possible—in this case, in the global scope.

If you're interested in the nitty-gritty details of let and const, check out what Dr Rauschmayer has to say about them in Exploring ES6: Variables and Scoping, and take a look at the MDN documentation on them.  

Lexical this & Arrow Functions

On the surface, this doesn't seem to have a whole lot to do with scope. And, in fact, JavaScript does not resolve the meaning of this according to the rules of scope we've talked about here.

At least, not usually. JavaScript, notoriously, does not resolve the meaning of the this keyword based on where you used it:

var foo = {
    name: 'Foo',
    languages: ['Spanish', 'French', 'Italian'],
    speak : function speak () {
        this.languages.forEach(function(language) {
            console.log(this.name + " speaks " + language + ".");
        })
    }
};

foo.speak();

Most of us would expect this to mean foo inside the forEach loop, because that's what it meant right outside it. In other words, we'd expect JavaScript to resolve the meaning of this lexically.

But it doesn't.

Instead, it creates a new this inside every function you define, and decides what it means based on how you call the function—not where you defined it.

That first point is similar to the case of redefining any variable in a child scope:

function foo () {
    var bar = "bar";
    function baz () {
        // Reusing variable names like this is called "shadowing"
        var bar = "BAR";
        console.log(bar); // BAR
    }
    baz();
}

foo(); // BAR

Replace bar with this, and the whole thing should clear up instantly!

Traditionally, getting this to work as we expect plain old lexically-scoped variables to work requires one of two workarounds:

var foo = {
    name: 'Foo',
    languages: ['Spanish', 'French', 'Italian'],
    speak_self : function speak_s () {
        var self = this;
        self.languages.forEach(function(language) {
            console.log(self.name + " speaks " + language + ".");
        })
    },
    speak_bound : function speak_b () {
        this.languages.forEach(function(language) {
            console.log(this.name + " speaks " + language + ".");
        }.bind(foo)); // More commonly:.bind(this);
    }
};

In speak_self, we save the meaning of this to the variable self, and use that variable to get the reference we want. In speak_bound, we use bind to permanently point this to a given object.

ES2015 brings us a new alternative: arrow functions.

Unlike "normal" functions, arrow functions do not shadow their parent scope's this value by setting their own. Rather, they resolve its meaning lexically. 

In other words, if you use this in an arrow function, JavaScript looks up its value as it would any other variable.

First, it checks the local scope for a this value. Since arrow functions don't set one, it won't find one. Next, it checks the parent scope for a this value. If it finds one, it'll use that, instead.

This lets us rewrite the code above like this:

var foo = {
    name: 'Foo',
    languages: ['Spanish', 'French', 'Italian'],
    speak : function speak () {
        this.languages.forEach((language) => {
            console.log(this.name + " speaks " + language + ".");
        })
    }
};   

If you want more details on arrow functions, take a look at Envato Tuts+ Instructor Dan Wellman's excellent course on JavaScript ES6 Fundamentals, as well as the MDN documentation on arrow functions.

Conclusion

We've covered a lot of ground so far! In this article, you've learned that:

• Variables are registered to their scopes during compilation, and associated with their assignment values during execution.
• Referring to variables declared with let or const before assignment throws a ReferenceError, and that such variables are scoped to the nearest block.
• Arrow functions allow us to achieve lexical binding of this, and bypass traditional dynamic binding.

You've also seen the two rules of hoisting:

• The First Rule of Hoisting: That function expressions and var declarations are available throughout the scopes where they're defined, but have the value undefined until your assignment statements execute.
• The Second Rule of Hoisting: That the names of function declarations and their bodies are available throughout the scopes where they're defined.

A good next step is to use your newfangled knowledge of JavaScript's scopes to wrap your head around closures. For that, check out Kyle Simpson's Scopes & Closures.

Finally, there's a whole lot more to say about this than I was able to cover here. If the keyword still seems like so much black magic, take a look at this & Object Prototypes to get your head around it.

In the meantime, take what you've learned and go write fewer bugs!