306

Babel's guide to ES6 says:

let is the new var.

Apparently the only difference is that var gets scoped to the current function, while let gets scoped to the current block. There are some good examples in this answer.

I can't see any reason to use var in ES6 code. Even if you want to scope a given variable to the whole function, you can do so with let by putting the declaration at the top of the function block, which is what you should be doing with var anyway to indicate the actual scope. And if you want to scope something more finely in an for block or something, then you can do that too.

So my instinct is to stop using var altogether when writing ES6 code.

My question is, am I wrong about this? Is there any legitimate case where var would be preferable over let?

Improve this question
12
  • 3
    I haven't tried this yet (since I'm not yet writing ES6 code), but it seems that using var as a conscious indicator that this variable is intended to be scoped to the entire function might be a useful "self-documenting" convention. Commented Feb 24, 2015 at 22:27
  • 14
    If you put a let statement right at the top of a function, I think it's just as obvious that you intended to scope it to the entire function. I don't think using var makes it any clearer than simply locating it at the top. Commented Feb 25, 2015 at 13:47
  • 19
    Honestly, I believe that the only reason var still exists, is backwards-compatibility. If it weren't for that, they'd have removed var altogether, or never introduced let in the first place, instead changing the semantics of var to what it arguably should have been all along. Commented Feb 25, 2015 at 16:24
  • 2
    @RayToal I agree with 97% of what Kyle Simpson says, but his reasons to keep using var seem thin to me, and not enough to warrant having a third kind of variable that jumps around. You can scope a let to a whole function simply by placing it at the top of the function, which is much clearer in intent than writing var in a block (in order to have it hoisted out of that block so you can then use it outside the block - weird). He warns that if you scope a let to a function then "it's just position that signals the difference, rather than syntax", but I think that's a good thing. Commented Jun 24, 2015 at 15:33
  • 2
    @RayToal I too read that article (just before reading this discussion) and I was really disappointed for his very weak case for var. the examples he presents for keeping var seem contrived -- and are based on severe coding errors. It's much better to run into an error and be forced to fix such errors than to use language functions that let one get away with it! What's next, advise to wrap everything in an try/catch to prevent crashes? The rest of that link is good but I don't agree at all with that particular part. Commented Jul 1, 2015 at 11:58

6 Answers 6

Reset to default
247

Doug Crockford discusses let at this point in his talk, "The Better Parts".

The point is, let avoids a source of misunderstanding, esp. for programmers with expectations set by languages with block-scope. A var has function scope (it declares a variable that's visible throughout the function) even though it looks like it has block scope.

var might possibly still be useful in an extreme case like machine-generated code, but I'm stretching hard there.

(const is also new and has block scope. After let x = {'hi': 'SE'} you can reassign to x, while after const y = x you cannot reassign to y. That's often preferrable since it keeps something from accidentally changing out from under you. But to be clear, you can still modify the object y.hi = 'SO' unless you freeze it.)

Realistically, your impression is right on for ES6: Adopt let and const. Stop using var.

(In another performance of "The Better Parts", Doug says why === was added rather than fixing the problems of ==. == produces some "surprising" results, so just adopt ===.)


A Revealing Example

Mozilla Developer Network gives an example where var does not work as intended. Their example is a realistic one that sets onclick handlers in a web page. Here's a smaller test case:

var a = []; (function () { 'use strict'; for (let i = 0; i < 5; ++i) { // *** `let` works as expected *** a.push( function() {return i;} ); } } ()); console.log(a.map( function(f) {return f();} )); // prints [0, 1, 2, 3, 4] // Start over, but change `let` to `var`. // prints [5, 5, 5, 5, 5]

var trips us up because all loop iterations share the same function-scoped i variable, which has the value 5 after the loop finishes.


Another Telling Example

function f(x) { let y = 1; if (x > 0) { let y = 2; // `let` declares a variable in this block } return y; } [f(1), f(-1)] // --> [1, 1] // Start over, but change `let` to `var`. // --> [2, 1]

let declares block-scoped variables. var confuses us by referring to the same variable throughout the function.

Improve this answer
12
  • 7
    He gives the same answer about adopting === instead of ==. The latter is broken but the ES standards committee didn't want to change it, so they added === Not quite sure what that means. == is not broken at all. It can simply be defined as equality comparison using coersion Check out github.com/getify/You-Dont-Know-JS/blob/master/… Commented May 12, 2016 at 3:53
  • 20
    @AmmarCSE that's a wonderful 39 page doc on implicit coercions. Who can keep all that in mind while programming? Doug meant "broken" as summarized in stackoverflow.com/a/359509/1682419 , in short, easy to get bit when value types vary more than we presumed. Can you predict all these? [ '1.0' == 1.0, [1.0] == 1.0, [1.0] == '1.0', ['1.0'] == 1.0, [null] == '', [null] == 'null', '00' == false, [] == [], [] == 0, [] == '', [] == false, [] == true, [010] - [4] == ' 4.0 ', !![0], !![1], [0] == true, [1] == true, 1 == [[1]], 0 == [[0]], '1' == [1] ] Commented May 12, 2016 at 6:54
  • 2
    right, most of those examples involve an array operand. It is easy to understand the result when you look into toString and how its implemented for Objects. However, if that is what is meant by broken then I completely see where that is coming from. :-) Commented May 12, 2016 at 7:53
  • 3
    why not use const whenever it's not mutable - just asking? I mean, the real choice it's not between let and var but rather between let, var and const Commented Jun 30, 2016 at 22:03
  • 6
    var works as designed, but not how many people expect. It's a usability bug, not an implementation bug. Commented Apr 26, 2017 at 0:37
26

If you have been writing correct code, you will probably be able to turn all var statements into let statements without any semantic changes.

let is preferable to var because it reduces the scope in which an identifier is visible. It allows us to safely declare variables at the site of first use.

const is preferable to let. Unless you need to mutate a reference, use a const declaration. This has all the benefits of let, along with reducing the presence of uninitialized variables and making code generally easier to reason about. If you aren't sure if you will need to mutate a reference, declare it const until you find yourself explicitly needing to mutate it, then declare it as let.

Improve this answer
5

I don't necessarily think you're wrong but there are caveats to using var. Essentially, let should help developers get around JavaScript's stupidity, particularly with naming conflicts. var, it seems, has a larger scope since it wants to go to the closes function scope. There will be times when you need var, like when you need a temp variable to be available within the scope of a block inside of a function, otherwise, preferring let over var will help developers with naming conflicts. On a lighter note, it's about time that ES6 introduced let.

Improve this answer
2
  • 4
    A temp var in a block is available inside the entire function, not block-scoped. It's a misleading feature. Commented Feb 24, 2015 at 23:06
  • For instances where I need to set a flag variable and check for it inside a block, var is what I still use. I do wonder though, if this is not the best way. Using let doesn't quite work though. Commented Mar 2, 2021 at 6:47
3

There is exactly one reason that I'm aware of to use var in current JavaScript code: For highly performance-sensitive code, it can avoid the performance overhead of the temporal dead zone.

The temporal dead zone (TDZ) refers to the interval within a block until the place where a value is declared and initialized:

function foo() { // Within the TDZ: Outputs "ReferenceError: Cannot access 'x' before initialization" console.log(x); let x; }

Tracking the TDZ within a JS runtime takes time. In this example, it's clear, but other scenarios may be more complex. For example, from https://vincentrolfs.dev/blog/ts-var:

function example() { const result = Math.random() < 0.5 ? useX() : 1; // 50% probability of a ReferenceError const x = 10; return result; function useX() { return x; } }

For this reason, the TypeScript project started using var for performance; their initial tests saw a ~8% performance gain on some of their benchmarks.

I believe that this is a very unusual case: unusually performance-sensitive code (considering the wide install base of tsc and the amount of processing it has to do) with unusually large engineering resources (to be able to explore these performance tradeoffs and to support the resulting code changes - the alternative of let / const really is easier to reason about).

Improve this answer
2

I tend to agree that only "let" should be used in es6. AFIK, redeclaring a "let" generates an error (which is good), while with "var", you simply override the value (though "strict mode" in es5 takes care of that too).

Improve this answer
-7

let means "let variable equal". It's a declaration, in other words, an initialization and assignment.

It exists in contrast to const which of course means "constant" -- which is the opposite of variable.

Some other languages use a prefix to the actual object instead of the object when declaring it (e.g. def is a shorthand for "define function" -- completely missing the point of what is being "def".

Let adds this semantic inconsistency to Javascript.

Logically, you could let a constant equal something as well, since the job of the "let" keyword is to assign memory.

The problem arises because the var keyword was introduced before const was supported, so backwards compatibility dictates that var doesn't necessary mean a variable. (It could also be used to assign a constant value.)

Hence, the introduction of let in the wrong position. To make sure that we remember that lexically, this is wrong, they also decided to change the lexical scope of let vs var, so the inconsistency is foremost in our minds when debugging.

In other words, let exists because people (meaning the language maintainers) thought that Javascript was too consistent, having mastered all it's idioms and idiosyncrasies, desire more.

Side note, var does not work in "arrow" blocks if you want to treat said blocks as closures (because var was introduced before treating blocks as closures), but let does.

Improve this answer
4
  • 9
    -1: pedantic, unhelpful, and primarily opinion-based. Commented Apr 26, 2016 at 23:07
  • fijiaaron is just joking with us here. Commented May 12, 2016 at 5:41
  • I am sympathetic to your dislike of the lexical form let because it is at odds with the tone of other keywords in the same category in JavaScript. Still this does not answer the question, and is not particularly well put. Downvoted Commented Oct 20, 2016 at 23:05
  • 4
    let is not just developers desiring more complexity. It is actually intuitively more understandable, because when you loop-and-close over vars, the closure maintains the last value of the var, but when you do the same over lets, each closure in the loop has its own value for let, a la the example by @Jerry101 above Commented Dec 28, 2016 at 13:33

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.