DEV Community

Cover image for Declaring Variables in JavaScript
Daniel Brady
Daniel Brady

Posted on • Updated on

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":

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.

Clip from "I,Robot": 'Hold my pie'

πŸ“– 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.

GitHub logo 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!

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

Top comments (3)

diek profile image

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

daniel13rady profile image
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 πŸ˜€

daniel13rady profile image
Daniel Brady • Edited

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

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;
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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