Variables in JavaScript: The ultimate guide

Variables in JavaScript

Variable statements in JavaScript like var, const, or let allows us to store or pass data in our application. By having a clear understanding of what variable statements do, we can prevent scenarios where protected data is leaked and changed. Lack of understanding of what they do, may increase the likelihood of having unexpected behavior scattered and difficult to maintain.

The article aims to teach you about the behavior/limitations of the variable statements making sure you don’t just use it but more or less truly understand why and when you need it.

What we’ll address

1. The var statement
2. The const statement
3. The let statement
4. Summary

1. The var statement

The most common approach back in the days of JavaScript, was the use of the var statement. It was simple, quick, and flexible to get the job done. If you needed to store a value, function, object or whatever it did it without any complaints. Some would say it follows the dynamic nature of JS, while others feel frustrated and start to counter plate life decisions, there is a solution to this problem. But before knowing the solution, let’s dive into why we should not use the var statement.

Once the code base is scattered with var statements, the issues were inevitable to detect or let’s say impossible. It revealed something known as what we call today — Temporal Dead Zone, a scary word, wait until you know what it does.

1.1. Temporal Dead Zone

To understand what Temporal Dead Zone is, you first need to understand the term hoisting. Hoisting is a concept that moves variable declarations and functions to the top before parsing the code. The problem with this is that you don’t see code being moved physically, but in the background which is not something most developers feel confident about.

Let’s say what we learn at school or by reading books is that the parser/compiler reads the code starting from the top, and moves down step by step (sequentially).

// Variable initialization
var name = 'Peter'; 
var email = 'peter@gmail.com';
console.log(`${ name } - ${ email }`); // Peter - peter@gmai.com 

As shown above, we initialize two variables name and age and then print out the result. This process makes sense right? We can’t show a variable before it is defined, however, with JS that’s not the case. Let’s see another example with hoisting:

name = 'Peter'; 
email = 'peter@gmail.com';
console.log(`${ name } - ${ email }`); // Peter - peter@gmai.com
var name, email; // variable deceleration

Notice we do something unusual where we declare the variables at the bottom and then assign values to it at the top. By looking at the code, one would say it returns undefined — not so fast!

With hoisting — all variable declarations and functions are physically moved to the top before the code is parsed. This rule only applies to variables declared, and not initialized.

Here's how it looks in the eyes of the parser when hoisting is applied:

var name, email; // hoisted! (moved to the top)
name = 'Peter'; 
email = 'peter@gmail.com';
console.log(`${ name } - ${ email }`); // Peter - peter@gmai.com

Alright, now I’m guessing you have a better understanding of what hoisting is (moving variable declarations and functions to the top), it’s time to clarify what Temporal Dead Zone is:

name = 'Peter';
console.log(`${ name } - ${ email }`); // Peter - undefined
var name; // Declarations are hoisted
var email = 'peter@gmail.com';; // Initializations are not hoisted

As you can see in the example, notice we get the name Peter but not the email, instead we get undefined. As mentioned, variable declarations are moved to the top, but not variable initializations since they are created in the order it was initialized, thus making it undefined.

If we change the var statement to const or let it would immediately output an error like ReferenceError: can't access lexical declaration 'name' before initialization.

1.2. The dynamic of var statement

When using the var statement, you can freely redeclare a variable or re-assign a value without encountering any errors.

Normally you would want to protect variables from outer changes. Why? Let’s say you have an if statement checking if the user variable is logged in or not by returning true or false for every request. Then years later someone uses the same name but changes it to a string value instead. Now your code fails, and you need to find a new way to protect it.

Here’s an example showing the flexibility of the var statement, many would argue that this is a weak point, and a strong reason for not using it:

// Redeclare variable
var name = 'Peter';
var name = 'John';
// or 
// Re-assign a variable
var age = 26; 
age = 27; 

It feels strange to do whatever you want with a variable and not encounter any errors. What do you think?

1.3. Block scope variable

A block scope variable is an enclosed body separated by brackets {}. In essence, when creating a variable, it should only be visible and accessible between the brackets.

However, when using the var statement that is not the case, let’s take an example where you try to protect your iPhone against thieves. So you put your iPhone home, and believe it is safe:

home: {
    var iphone = 'Iphone 10s';
}
console.log(iphone); // Iphone 10s

As you can see, even though your iPhone is initialized within a enclosed body, someone is still able to steal it - var is property of the global object.

Personally I believe it is a strange behavior even though it does what it’s intended to do, it can lead to few bugs that are difficult to detect. To be on the safe side, just go with these block scope statements like const or let to avoid variables being leaked in outer contexts.

2. The const statement

The purpose of the const statement is to protect variables and values from being changed. Once you declare a const variable, any changes applied leads to an error.

For instance, if someone tries to change a declared variable name - the parser returns a SyntaxError. Compared to the var statement, const statements are only visible in the context it was declared in.

Scenario 1: Change Value of const

const CEO = 'Elon Musk';
CEO = 'Jeff Bezos'; // outputs: TypeError

As shown above, if a developer tries to change the CEO from Elon Musk to Jeff Bezos which is Elon’s worst nightmare, a TypeError is prompted.

Scenario 2: Redeclare a variable name

const CEO;
const CEO; // outputs: SyntaxError

As you can see, if we try to redeclare a variable name that has already been declared, it returns a SyntaxError.

Scenario 3: Using const in loops

const engines = ['engine 1', 'engine 2', 'engine 3', 'engine 4'];
for (const i; i < engines.length; i++) {
    console.log(i);
}

As shown in the example above, a common mistake is to use the const variable in a for-loop statement because for every iteration, the const variable is changed ( increments by 1). As we’ve talked about, a const variable can’t be redeclared.

Tip: To solve this issue just use the let statement instead.

Scenario 4: Block scope

{
    var engineType = 'Merlin Engine';
    const rocketType = 'Falcon Heavy';
}
console.log(engineType); // outputs: 'Merlin Engine'
console.log(rocketType); // outputs: ReferenceError

As shown in the code example above, we initialize a const and a var variable inside a block scope. Later we try to access both variables, the var variable returns the value without any errors, while the const variable returns a ReferenceError.

3. The let statement

The let statement is a block scope variable similar to the const statement except the value can be changed. Here are a few scenarios to further describe it following the same style as shown previously:

Scenario 1: Change Value of let

let CEO = 'Elon Musk';
CEO = 'Jeff Bezos'; // We have a new CEO

By using the let statement, we can change the value without any errors.

Scenario 2: Redeclare a variable name

let CEO;
let CEO; // Outputs: SyntaxError

As shown in the example, trying to redeclare a let variable gives a SyntaxError, same behavior as the const statement.

Scenario 3: Block scope

{
    var engineType = 'Merlin Engine';
    let rocketType = 'Falcon Heavy';
}
console.log(engineType); // outputs: 'Merlin Engine'
console.log(rocketType); // outputs: ReferenceError: rocketType is not defined

As shown above, once the let statement is declared or initialized, it can’t be accessed from outer context. In general, this type of behavior secures our application from outer changes, and helps us to protect values.

Summary

When dealing with var statements, we encounter issues that are difficult to debug such as the temporal dead zone, lack of protection, and lack of error messages to guide us in the right direction. As a good practice, and something I recommend is to go with const or let thus these are block-scoped. In short, when you define a variable you can be certain they are only visible in the bounded context (within the brackets). This removes the pain of having variables leaked in your application and changed by outer context. In overall, you have more control of what is happening, but most importantly if something goes wrong, an error is prompted.

Before I let you go, remember:

The let and const statement shave to broad differences from var (Answered by Joews on Stack Overflow).

1. They are block scoped.
2. Accessing a var before it is declared has the result undefined; accessing a let or const before it is declared throws ReferenceError:

console.log(aVar); // undefined
console.log(aLet); // causes ReferenceError: aLet is not defined
var aVar = 1;
let aLet = 2;

You can find me on Medium where I publish on a weekly basis. Or you can follow me on Twitter.

P.S. If you enjoyed this article and want more like these, please clap ❤ and share with friends that may need it, it’s good karma.and