Stop using var
for declaring variables
If you are new to JS or been with it for quite some time then for the most part you probably be using var
to declare your variables which is fine but it's not the most efficient & preferred way of declaring variables.
But why? And what should I use instead of var
?
Let's find out!
Function Scope vs Block Scope
Block Scope
Most of the programming languages nowadays support a concept known as Block Scope, which means if a variable is declared within a block of let's say a for
loop then that variable will not be accessible, outside that for
loop.
If the variable of the same name is created outside the for
loop then it will be treated as a different variable in the programming language which supports block scope.
Let's understand this through some pseudo-code:
function() {
//This variable belongs to function scope
name = "I am a string!"
for {
print(name)
}
}
Here we have a function
with a for
loop inside and a variable named name
.
We are trying to read the variable in the for
loop which is a child of the function
.
When we run this command, we get this output:
I am a string!
This indicates that we can successfully read variables present in the Function Scope.
Function scope is limited to the function itself. We cannot access the name
variable from outside the function.
Let's try this one more time, but this time we will try to access the variable in the function
from for
loop.
function() {
for {
//This variable belongs to block scope
name = "I am a string!"
}
print(name)
}
When we run this code, we get an error that the variable is not declared i.e. variable doesn't exist.
This indicates that we cannot access variable present in the child block but the child block can access the variables present in the parent block.
This is known as block scope where the access of the variables is limited to that specific block only. Variables present in the function block can be easily accessed by the child blocks but the opposite is not true.
Let's talk about JavaScript now!
The block scope we just saw is applied in popular programming languages like Java & C++. Developers prefer using block scope as it helps them to make their code more efficient & less prone to errors.
Fortunately, with the release of ES6, JavaScript now supports Block Scope as well.
We can create block scope in JavaScript with the help of let
& const
keywords while declaring variables.
What are let
& const
?
let
& const
are JS keywords like var
which can be used to create variables.
This is how we declare variables using var
:
var name = "I am a var variable."
However, variables created using var
will be accessible throughout the function ie they will live in the function scope.
But as we just mentioned we want our variables to only be accessible within the block, it is created in.
To achieve this, we eliminate the use of var
for declaring a variable and use let
& const
instead for variable declaration.
let name = "Bobby"
const birthday = "16 June"
What's the difference between let
& const
?
-
let
- Variables created using thelet
keyword can be easily modified and overwritten. You can use this keyword the same way you will usevar
-
const
- Variable created usingconst
cannot be changed or modified. You can use this keyword for declaring a variable that is expected to remain constant throughout the execution so that it cannot be changed or modified by any means.
Final Takeaway!
Stop using var
and start using let
& const
for variable declarations.
Support
Thank you so much for reading! I hope you found this blog post useful.
If you like my work please consider Buying me a Coffee so that I can bring more projects, more articles for you.
Also if you have any questions or doubts feel free to contact me on Twitter, LinkedIn & GitHub. Or you can also post a comment/discussion & I will try my best to help you :D
Top comments (43)
Using const only means that the variable will always have a reference to the same object or primitive value, because that reference can’t change. The reference itself is immutable, but the value held by the variable does not become immutable.
Hello Ibrahim, thanks for the explanation but it's probably too complex for our targeted audience, we will try to simplify your explanation and update our post accordingly.
Have a great day!
What target is that? the "I just learned to walk"? Constants are a basic concept of programming. And to point out that a Javascript const is not the same as a C const is not to hard.
Also you're completely right and I don't know why var still exist.
For historical purposes, i.e. backward compatibility.
they could deprecate it. Like other stuff. It could be used but with a warning. In all MSDN docs you will find var declarations. That's not just about backward compatibility.
Biggest major oddness about var, apart from hoisting and function scoped, is that you can declare it multiple times.
its because var is not realy declaring a variable like let or const, with var you adding something to this.
So this works:
var a = "a";
console.log(this.a); // 'a'
This not:
let a = "a";
console.log(this.a) // undefined
So every time you use var its like adding something to this. Thats the "function scope".
It seems that var outperforms both let and const in 2017.
quora.com/What-is-the-performance-...
Thanks for sharing. Im gonna work it through and look if this still the case. 9 years difference (according to the engineer discussion)
Hey Lars! I will be replying to this comment of yours:
What target is that? the "I just learned to walk"? Constants are a basic concept of programming. And to point out that a Javascript const is not the same as a C const is not to hard.
Also you're completely right and I don't know why var still exist.
Alright, so our targeted audience is mostly comprised of people who are in their early stages of the coding journey and are just getting started, if you check our profile you will find most of the tutorial belong to that category only.
One of the main reasons we prefer to limit our audience is so that we can match the requirements of a beginner and make sure our explanation is understandable to them.
I hope this answers your question!
Have a great day!
2021-Feb-25:
Context:
doesn't work because of the block scope
const something
is constrained to.var
is scoped to the execution context sowill work. Otherwise one needs to resort to
Just because you don't use it doesn't mean that it isn't useful.
var
add no real benefit overlet
in the case, and will break if I cover everything with ES6 block scopeOr is it that
let
doesn't add any real benefit in this case - and it is noisier as it requires a separate line of code just for the declaration.And I don't understand what you mean with "will break if I cover everything with ES6 block scope".
var
can be scoped with IIFE, unless you expect scope leak.let
andconst
can be scoped with just{}
alone.One line of code doesn't matter that much (unless TypeScript - you need to and
let
type declaration).I don't want to see this kind of bug.
If that is an issue, an entirely different conversation is necessary: Why is this type of code running in the Global Scope?
var
is constrained (does not leak) within functions and within modules - so nothing about ES2015 or ESNext will make code that usesvar
"break".f(m)
going to get undetected given thatm
is going to beundefined
?m
?m
anyway - likely two different names are more intention revealing.In the majority of cases
let
andconst
are better - but that doesn't mean all cases.they whole problem if the hoisting of var. Block Scope is safer in your daily programming. Why to I need to care of hoisting.?
You only need to free resources when you doing something you don't wan't anything to access it later. The garbage collector will do the rest for you. So this example is shit. If you know how to program without side effects there is no real case you would go into this.
var could causing side effects if you don't carefully watch that you don't need it in the function. It has no benefit except you call hoisting one. So you want hoisting. And in my opinion (because that's all here) its shit.
There's also "let", which I think sucks as well, but at least it's not var.
Nice explanation of concepts, I really liked it.
The only thing I can't agree with is the title of the post. There is no point of avoiding
var
altogether if you understand its scope and impact.Hey Vaishali!
We are very glad to hear that you liked our post :D
And yes we understand your concern regarding the title, I'll report it to my editor. But our main goal here is not to make judgemental titles, instead, we try to emphasize the overall takeaway of the post, we love people like you who always come forward and share their views and opinions about every single aspect of our work!
Thank you once again and have a really great day!
Sorry for directly targetting the title but the only point I wanted to make is that though
let
andconst
are good addition to the language,var
still holds its value and is still useful in many cases.I love JS ♥️ and even though ES6 is booming, I still respect ES5 for its simplicity 👍
Can you give an example where
var
is better? I've never come across one (unless targeting ES5 without transpilation for some reason).Did I say
var
is better? 🤔Can you give example of an application which would be impossible to develop without
let
andconst
?let
andconst
are not essential features, they are just good to have things. With their introduction,var
doesn't become obsolete. That was my point 😊You didn't say it's better overall, you said it's "useful in many cases". That's what I was asking for clarification about, because in my experience it's only useful as a transpilation target — when writing your own code,
const
andlet
always have better semantics and lead to fewer bugs. But I was curious as to what your counterexamples would be.There can be many examples. I can write an entire blog post about it 😅
There is a difference in the way JS engine treats
var
andlet/const
when it comes to initialisation process.Also, I don't think either of these have better semantics, they just have different semantics.
And the amount of bugs have nothing to do with language features, in my experience. It depends on the developer's understanding of language.
😉
Cute example, indeed!
But
let
only gives you a little bit more convenient way to handle this rare scenario.You could certainly do it without
let
, if you are good at variables scopes, hoisting, execution context etc.Clearly,
let
is just a luxury but not necessity.Getting back to my point: Though
let
is useful, we don't have to stop usingvar
as it is useful in its own ways. Consider this small example:The above will result in ReferenceError, but will work fine if
let
is replaced byvar
. There can be many more scenarios wherevar
will be better suited as compared to the other options. After all, developers can choose to use either and get the things done without error, given that they know the language well.My concern is not about
var
vslet
, both are useful. I just wanna say that developers should uselet
andconst
wherever suitable, but there is no point of completely avoidingvar
as it has its importance in certain scenarios.✌
JavaScript for-loops are… complicated - HTTP203 (2018)
I think the original intent was :
i.e. while
idx * 1000
"works" because it is used whendevWhoKnowsHowToUseVar
runs rather than whenconsole.log
is scheduled - havingidx
as an explicit parameter of the function is clearer.The problem with "Stop using var for declaring variables !!!" - you need to be able to read code - so even if you yourself never use
var
, you still have to understand how it works to understand code from other sources.The way
var
is hoisted is yet another unnecessarily confusing thing about it. This would be easier to reason about if the declaration was written at the start and split from the assignment, which would work withlet
.Agree with this. JS devs should definitely learn about
var
so they can read legacy or transpiled code. Then they should (personal opinion) add a rule to their linter that disallows writing it in their own code.To be honest, this whole topic is about personal opinion/preference of developers with respect to variable declaration.
I've been working with JS for many years and 3 of my major projects are still completely powered by ES5, and believe me, I never had issues reading or understanding code with
var
.In my personal opinion,
let
is only giving some convenience at lexical level which is certainly useful in many cases, but it doesn't replacevar
if you see from perspective of JS engine.It's only confusing if you're pretending to work (or rather be working) in "some other language". That is simply how
var
works in JavaScript - the "hoisting" is a natural consequence ofvar
being function or globally scoped. For consistency sake, style guidelines recommended to put allvar
declarations at the top of the function and to resist the urge to pretend as ifvar
was block scoped.Acknowledging the "personal opinion" qualifier here, however:
From that perspective a warning that can be disabled locally seems more appropriate.
"A warning that can be disabled locally" is exactly how eslint (and I think all common alternatives) already work.
Thus removing any perceived advantage from using
var
in the first place.I somehow doubt that "hoisting" was ever seen as an advantage of
var
- it's simply an emergent property of howvar
was implemented by the runtime - one that needs to be taken into account.The obvious intent here is to cross the block scope barrier but in doing so
something
is now available in the entire function scope which shouldn't be construed as an invitation to usesomething
before or aftertry/finally
.Has the advantage of not being assignable before the
let
but still exists past thetry/finally
.PS: Personally I'd likely go this route:
rendering the entire
var
vs.let
discussion moot.@Vaishali JS
What is that for a philosophy. Javascript has by far the most bugs writting I ever detected in any language. Because someone says you need to understand the language. No. You write an
var
at the end of the line is not understanding the language, is writing bad code.Most of this because
You done this? I hope not that is so fucking bad programming. Even when using var, declare it before you try to use it.
That's not an argument for
var
it's completely against it. Any developer watching your code needs first to be clear there is novar
hidden in your function. And when you have big projects you don't want to do this. You want to have a clear view of functions. And don't want to read until the last line to be sure there was anvar
.I didn't make it up - and crass language doesn't strengthen your argument.
I also don't believe hoisting of
var
was ever an actual, deliberate feature - it's simply an explanation (and name) of its behaviour given that it has function scope and can be declared anywhere within the function. Hoisting of function names on the other hand is quite deliberate because that way multiple functions can reference one another regardless of source order.Are you talking about JavaScript or code written in JavaScript?
Lots of junior developers write code in JavaScript. Junior developers write "inexperienced" code in any language. And juniors not exploring other languages besides JavaScript probably have a hard time to improving their use of JavaScript.
It's also used in mission critical projects.
For example starting in 2014 eBay shifted from their Java-based stack to a Node.js-based stack - Marko which essentially runs their web front. - so what is your point?
Again forget about any expectations that you may have from some other language.
JavaScript's behaviour aligns with the web's resilience model. From the browser's point of view JavaScript is the least important aspect of any page it loads:
JavaScript fails silently because the browser doesn't want to punish the end user for a developer's negligence of testing their code properly. This was in an attempt to preserve the information that could be conveyed by the content, markup and visual design.
It's client-side rendered SPA's which turned everything upside down. It's ironic that about the time the back end "discovered" microservices (2005-2011) the front end "discovered" monoliths in the form of SPA'a (2002-2003). Going by that MPAs should be coming back as the front end version of "microservices".
I'm personally not thrilled about Node.js being used in production on the back end - but it is. I'll also admit that JavaScript is far from the pit of success we would all like to have.
The problem with JavaScript is that it is deceptively easy to learn just a little bit of it; possibly operating on an erroneous mental model - but it actually takes quite a bit of effort to know JavaScript well enough to use it well.
@larsonnn
What a vague comment is that!
I am myself using JS in a large missing critical project. We are a team of 20 JS develpers and we are using only ES5.
We have our own ways of achieving block scope using
var
and we have our own patterns for declaring globals!Its definitely not about the language, its about the developers and the way they choose to use the language 😊
I was not answering you peerreynders
But here:
I didn't say you did. The example is still a worst one. What you learn is, with
var
its not a problem if you code bad. And using var only that you can use it in finally or above yourvar
statement is for me bad code. (Opinion here)What's written in javascript ofc.
You're right. That does not mean I need to accept the fact that
var
is for now. In my programs there is novar
and I don't miss it. And I guess the most developers will not miss it if it's not available.in the 90s or early 00's yes. If you take v8 for example, it is clear that JavaScript is NOT the least important aspect. Also JS is one of the most used Languages. Or I didn't understand you here.
Ok fair. From the financial view. But do you wan't to run automated cars with javascript? Or Rockets to fly? Ofcourse not, it's fine. But that does not mean we should learn how to programm bad. And the language can support for writing easy safe code. And with node-js as your backend. I don't want some easy errors to make when it comes to writing Data in the Database. And we use so much microservices in JavaScript that we could raise the bar for what the language should have. If not, I don't see in the longrun JS only lose.
JavaScript is so quickly to mess up like no other language. And that's my whole point. Why sticking with
var
there is no use case. The only use cases presented was for hoisting. I don't see any other argument. Its not faster, its not saver. Its not intuitive to declare under the usage:Why should I do this? Its not intuitive. You would write more like this:
And that's just the worst example. Because you can write more elegant. But that's another topic.
I know that will not make JS the perfect language. And perfection will never be reached, because JS has many other things we could discuss.
lots of junior developers write python or java code also. I see code from "experienced" developers which do the same misttakes. Or don't care and that's by far the worst.
this will switch every time. That's normal. That's like haircuts. With nextjs or nuxtjs they just sell SSR as a new feature. (Yeah, it's a little more... But common).
[
var
,let
]const
is one statement to much.It's not about your project. And I don't care if you have 20000 JS developers. Its about the language. If you can't understand that the language can be better with more sense in it. I guess you live in your bubble.
Because you can use var and have 0 errors with it, does not mean its good to have var. And I don't care about ES5, it's old.
No language is good or bad in its own. Its only the way developers understand and use it.
Edit:
Just to add, ES5 is certainly old but most developers are not relying on ES6 unless they have babel/webpack or other third party tools to transpile ES6 into something that browsers care about.
There are still use cases to use var, are we going to see those too?
Thanks for the suggestion Mundo! Will send this to our editorial team!
And yes var hai its use cases but talking about ES6, using let and const are considered as best practices for modern web application development.
Have a great day Mundo!
Haha, this headline is usually whisper yelled thru my teeth.
Although, I'd point out:
a const is a constant, and not a variable.
How about we just throw JavaScript out of equation and glorify Jquery and it's sugar coated syntaxes!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.