Declaring Variables in JavaScript

The variable declarators available to us in JavaScript, and more specifically when to use them, are a hot topic of conversation these days. A few weeks ago, I read an article called "Another var vs let vs const":

Another var vs let vs const

Stefano Armenes ・ Jan 6 '20 ・ 1 min read

#javascript #beginners #webdev #community

Though the title made me smile, my response to the advice given was less positive:

I think we can summarise everythings in a few lines:

• var: why? if you can avoid it, do it;
• prefer const usage if possible of course (together with an immutable approach when updating objects)! But don't be scared using let, especially if the scope of your variables is small, for example inside a function.

To be clear, I think it is very nice summary of the reigning opinion I've been exposed to; but the gospel-like way in which it is given triggered a knee-jerk reaction of mine, which is to immediately question bold statements made without supporting arguments.

I realized I don't entirely agree, but I couldn't articulate why. So it got me thinking many hours of thoughts. And with deep thought comes opinions:

Immutable approach to state management? ✅
Prefer const? 🙅
Avoid var? 🙅
Embrace let? ✅

If you choose to follow my dive into this particular rabbit hole, I'd appreciate feedback!

The tools: a miniseries

I've written a miniseries of posts that encourages deep thoughts about variable declaration in JavaScript.

📖 Most of the differences between our variable declaration tools pertain to (lexical) scope, so if you don't have a firm grasp of that subject, I highly recommend Kyle Simpson's short book Scope and Closures; it's a fantastic resource, and I think Kyle does a great job at explaining this area of language design in an easy-to-follow way.

getify / You-Dont-Know-JS

A book series on JavaScript. @YDKJS on twitter.

Each post dives deeper into one of JavaScript's variable declarators, and rather than constitute a sequence they are intended to be standalone, interrelated references.

I have chosen to give them identical structures and also tried to keep the examples* as similar as possible for easily comparing and contrasting the information in each, should you choose (and I strongly encourage it 😄).

I hope they help you make better decisions about which one is the right tool for holding a particular bit of your data. 🙏 I've definitely learned a lot from trying to write them!

Using JS: var

Daniel Brady ・ Jan 20 '20 ・ 7 min read

#javascript #thinkdeep #spec

Using JS: let

Daniel Brady ・ Jan 20 '20 ・ 9 min read

#javascript #thinkdeep #spec

Using JS: const

Daniel Brady ・ Jan 20 '20 ・ 10 min read

#javascript #thinkdeep #spec

*For the curious, I'm using Carbon with some custom settings to generate pretty pictures from code.

Comments

[diek]

Why that obsession with immutable objects? I don't understand it.

[Daniel Brady]

Ooo, thanks for asking. I'll have to write a post about mutable and immutable approaches to state management, I think it's a fascinating topic! And another case where people tend to use one programming tool over another without really thinking deeply about why.

But with respect to the "obsession over immutable objects" that is so commonplace these days, I think it has a lot to do with the types of problems people are solving (many of which fall into the "immutable objects are great for this" category), as well as the increase in mental overhead that managing application state can put on us as developers.

Not the only reasons, of course, it's a broad topic, just my off-the-cuff impression. I'm looking forward to digging deeper 😀

[Daniel Brady]

Someone asked me a really good question about const offline, so I recapped my answer in the comments:

Daniel Brady • Jan 21 '20

Regarding this statement I made:

Sometimes, I want to give a name that never changes meaning, to a value that never changes. No single construct in JavaScript can enforce this.

Someone offline (to DEV, anyway) gave me a really good "But what about this..." example, so I wanted to share it and elaborate a bit on why what my statement still holds.

Basically, they wanted to know why this simple declaration doesn't provide complete immutability:

const x = 42;

My answer is that, at least according to my own understanding of JavaScript, it does. However, it is not because of const alone. This declaration creates a box with contents that can be neither replaced nor modified because of two things:

1. const prevents re-assignments
2. numbers are immutable value types

If you replaced the initial value 42 with an object (arrays are a kind of JS object), then all of a sudden you've got a mutable value in an immutable variable, and the contents of your const box can be modified because the value itself can be modified:

/* Totally valid but very confusing so I don't like using `const` for this 🙂*/
const config = { some_setting: 42 }; // immutable variable
config.some_setting = "cat"; // mutable value

This is what I meant when I said that no single construct in JavaScript can enforce complete immutability. Hope this helps!