var vs let vs const

Eduardo Henao — Thu, 11 Apr 2024 14:26:18 +0000

This is one of the most common questions you'll face in an interview, and it is very important to know that there are 3 ways to declare variables (and 1 more) in JavaScript.

It's common to start by the bad practice, but in this occasion, I'll start by the good, so in that way you already know what should be used.

You should be always use let and const.

This is going to make sense in a couple of minutes.

Let's start with let.

This word allows you to declare a variable, which its value can change (reassignment). And cannot be re-declared.

let myName = "Eduardo"; // Variable declaration 🌱
myName = "Octavio"; // Variable Reassignment

let myName = "Sarah"; // ❌ Re-declaration: This produces an error

Now... what happens with const?

It's the just same behavior than let, but you cannot reassign the value of a constant, as its name says it should be constant.

let's see how it works:

const myIdNumber = 2930493843; // constant declaration 🌱

myIdNumber = 12345678974; // ❌ Reassignment of a const: This produces an error

const myIdNumber = 45678215687; // ❌ Re-declaration: This produces an error

Great! Now you know what's the difference between let and const, but... What happens with var?

Well, this is something related with 2 main things:

The Scope
The re-declaration

var was the very first option that JavaScript had to create variables, but it has some caveats. This is a pretty opiniated topic and you'll find that some people defend this, and that's okay. But you need to understand the risk of having those "weird" behaviors to be prepared to deal with them.

var has a global scope

The first thing you need to know about var is that its scope is global, how is that?

function someFancyCalcFunction() {
  var x = 293847191237413;
  console.log(x); // 293847191237413
}

console.log(x); // 293847191237413 
/* 
You have access to the variable value 
out of the function where it was initially declared.
*/

Let's analyze the previous snippet, I have created a function and I have declared a variable inside of it, but here is the "non-good" part and it is that I'm being able to console it out of the function scope. And the non-good doesn't end there, I can modify the value outside of the function which can lead id pretty lexical complexity and hard to read and you can lose pretty easily the idea of why that variable was created and where I should stop using it.

var can be redeclared

This is one of the most dangerous features of var usage. And that's because you can redeclare a variable with the same name. Imagine that you create a variable at the very beginning of your code, and you use that variable, but you forget about the name, and the value of that variable. and then 5000 lines after (this is a pretty bad practice, but I just want to create a scenario) you create another variable with the same name. Whit var that's possible and that can lead in several problems, specifically if you are working in a dev team.

Here is an example:

var myIdNumber = 2930493843; // constant declaration 🌱

myIdNumber = 12345678974; // ✔ Reassignment is allowed

var myIdNumber = 45678215687; // ✔ Re-declaration is allowed

What the f#$k is strict equality.

Eduardo Henao — Wed, 10 Apr 2024 14:06:24 +0000

Sometimes I see some memes regarding Javascript equality and yeah, some of them are pretty funny, here is my favorite.

I see that there is a common pattern, this "weird" behavior always happens with the double equal sign operator == which we can call loose equality. This happens because it perfoms the IsLooselyEqual algorithm, and the Javascript engine will perform a typer cohertion to try to match both sides in type and value.

How can avoid these "weird" behavior?

Well when you use the triple equal operator === javascript doesn't convert at all the type of your values, and then performs a comparison and checks that both values and types, and if both are for example the same number and the same type, the result of the comparison will be 'true'.

DEV Community: Eduardo Henao