Cover image for 1. let, const and ... var
Blue Turtle

1. let, const and ... var

islam profile image Islam Sayed Updated on ・3 min read

ES6 has introduced some new syntax features. One of them was key words const, and let to declare variables. Let's talk about why they are preferred over var.


var has a function scope. This means it is accessible anywhere in the function it is defined inside. See this example:

function buyHerChocolate(onDiet) {
    if (onDiet) {
        var decision = "Don't do it!";
    } else {
        var decision = "Go buy it!"
buyHerChocolate(true);//"Don't do it!"
console.log(decision);//Uncaught ReferenceError: decision is not defined

As you see decision variable defined with var was availabe inside the function scope, but when we tried to log it outside the function the console throws an error decision is not defined as if it's never existed.

On the contrary, let and const have block {} scope.

function buyHerChocolate(onDiet) {
    if (onDiet) {
        let decision = "Don't do it!";
    } else {
        let decision = "Go buy it!"
//"Don't do it!"
//Uncaught ReferenceError: decision is not defined
console.log(decision);//Uncaught ReferenceError: decision is not defined

Surprise! Logging the value of decision inside the expression block resulted in the predicted string while doing the same out of the block throw error and out of the function scope also throws an error.

The same happens with const.


Variables declared with var are hoisted to the top of their scope. It is important to notice that the variable declaration is what is being hosted not the assignment.

var x = 5;//undefined

What happened?! The console.log() function will not get executed until hoisting any var variable. Therefore, var x; will go up to the top of the global scope. Then console.log(x) is executed and logs undefined, because x has no value at that time. The x is assigned the value 5. It will look like this:

var x;
x = 5;

Because of that if we console.log(x) after that it would log 5 to the console.
This quirky behavior can introduce bugs in larger programs.

let and const are not hoisted.

const x = 5;//Uncaught ReferenceError: x is not defined

Declaration & Assignmentβœ’οΈ

var variables can be re-declared and reassigned different value multiple times in the same scope.
let variables can not be re-declared but can be reassigned in the same scope.
const variables can not be re-declared or reassigned in the same scope. In addition to that they must be declared and assigned a value at the same time. So we can not do that:

const y;//Uncaught SyntaxError: Missing initializer in const declaration

But we must do that:

const y = 5;

So if your variable would have changed values, declare it using let, if not always use const.

These differences between them and var will prevent naming conflictions.


For the mentioned reasons you should use const in all cases except when the variable would be reassigned new values. At such cases use let instead. Most of articles recommend developers to avoid using var. Why would anyone use var anymore?!

Do you agree with me about that? Please, leave a comment telling me your opinion.

For further readings:

πŸ“ŒThe Difference Between Function and Block Scope in JavaScript

πŸ“ŒDemystifying JavaScript Variable Scope Hoisting

πŸ“ŒWhat is Hoisting in JavaScript?

Posted on by:

islam profile

Islam Sayed


A Freelance Front-End Web Developer, tech writer, and mentor at Udacity.

Blue Turtle

Web Development Blog


markdown guide

var is useful with Jest.

try {
  await foo()
} catch (e) {
  var error = e

Honestly, I would simply:

await expect(foo()).rejects.toThrow(/foo/)

Since foo is an async function, it implicitly returns a promise so you can use the .resolves / .rejects matchers and then use the toThrow method, and this accepts a regex or string to match the error message property. IMHO it reads more semantically correct.



The toThrow API is quite weird.
If you pass a string, it matches it anywhere, so 'foo' and /foo/ is the same.
And if you want to strictly match the whole message, you need to do

.toThrow(/^literal message$/) // RegEx with ends
.toThrow(new Error('literal message')) // The Error class does NOT matter in this case.

If you actually care about the constructor, you have to pass just it.


I use


a lot nowadays.


Any reason to not put the expect inside the catch bloc ?


Yes. If it doesn't throw assertion wouldn't run, and the test would pass.
You'd have to do

try {
  await foo()
} catch (e) {
  var error = e

Personally, I'd just go with

await expect(foo()).rejects.toThrow('foo')
// Or, if final in the test:
return expect(foo()).rejects.toThrow('foo') // doesn't require `async` `it`

(No need for expect.assertions(1) since the expect runs synchronously inline)


Could you please explain why you use only var with jest?


Oh, no. I only ever use var in this scenario. Lets me skip out of the block scope without a separate variable declaration. And if no error happens, the variable is just undefined.

Aha :)
So here is a place where var is still useful πŸ˜‰

Did you mean:

let error
try {
  await foo()
} catch (e) {
  error = e
expect(error.message).toMatch('foo') // you can use string literals if you don't have a complex RegEx

If i see var in your codebase, you're doing it all wrong, even seeing let would rise suspicions...


You know what would be RADICAL?
Renaming this article to const, let, and... var, to comply with the the good, the bad, and the ugly formula.


Did I? Or did I make you exhale audibly through your nose? :D

If I wasn't at work, I would definitely do so :D

So, only laughing is allowed at work.
Got it.

Hmm... animated GIFs work, but not PNGs?


Great Article.
Thanks for sharing this with us, Islam!


My dear friend, thank you.