3 reasons to use 'var' in JavaScript
Tags: javascript, webdev, beginners, programming
Published: 2021-11-08 22:19:53

The `var` keyword was JavaScript's first way to declare a variable. It fits, right? Var, variable, it's in the name. But like the Joker, `var` is more than pretty face -- it has some baggage. As a beginning programmer, or a seasoned one dipping your toe into the seedy underbelly of JavaScript development, you maybe be wondering when you should use `var` to declare your JavaScript objects and functions.

Never fear. I have 3 reasons for you to use `var` in your next JavaScript project.

## You love tradition and spurn anything new

Var may be the oldest keyword to declare a variable, but it is by far the only one. It's younger cousins, `let` and `const` exploded onto the scene with [ES6](https://en.wikipedia.org/wiki/ECMAScript#6th_Edition_%E2%80%93_ECMAScript_2015) (over 6 years ago as of this writing!). But if sticking to old norms fraught with perils is your thing, keep using `var` and leave these upstart keywords to listen to their terrible pop music and complain about their parents.

## You prefer mutability, even when you don't

Var has the troubling distinction of creating a variable of any type, which can then be changed to a variable of any type later. That's right, the number you declared on line 4 just became a string on line 17 and a boolean on line 109. This type flexibility is a key feature of JavaScript, but it can be avoided. But if you too like to live dangerously, keep using var.

## You like leaky scopes

Prior to ES6, JavaScript variables were always defined at the function scope. In a lot of cases, this meant variables were *global*. JavaScript didn't enforce block-level scopes such as inside a `for` loop or `if` block. So a variable declared with `var` would be *hoisted* to the top of its function scope. In other words, the variable declaration moved to the top of the current lexical environment with a value of `undefined`. A common issue arising from hoisting is that such variables are accessible outside the block scope, where the developer may not expect them to be. 

A subtler and more difficult to detect bug can happen here as well, [variable shadowing](https://eloquentjavascript.net/1st_edition/chapter3.html#p468c043e14dd0d54). Rarely this may be desired. If that is you, `var` is your hero.

## There must be a better way

If you made it this far, you're probably seconds away from pounding out a fierce comment about how I'm wrong about `var`. The truth is, no one should be using `var` in any JavaScript code except for a history lesson. Even then, it should come with a footnote that says something like, "please don't ever do this."

`Let` and `const` have been available in [every major browser for the last 6 years](https://caniuse.com/?search=let). This is really, really ancient in frontend years. `var` isn't just the parent misunderstanding their teen, it's the great grandparent everyone loves but no one invites to the *fun* parties.

`Let` retains JavaScript's flexible type system while enabling block-scoping. `Const` creates a -- you guessed it -- constant variable in block-scope. `Const` creates a variable that cannot be reassigned, but similar to most other languages, `const` objects can have their properties mutated. These two alternatives to `var` should cover every use case you have. Even if you are in the tough spot of needing to support truly archaic browsers, don't use `var`. Use a tool such as [Babel](https://babeljs.io/).

So please, please, do not use `var`.