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
constusage if possible of course (together with an immutable approach when updating objects)! But don't be scared usinglet, 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!
*For the curious, I'm using Carbon with some custom settings to generate pretty pictures from code.
Top comments (3)
Why that obsession with immutable objects? I don't understand it.
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 π
Someone asked me a really good question about
constoffline, so I recapped my answer in the comments:Regarding this statement I made:
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:
My answer is that, at least according to my own understanding of JavaScript, it does. However, it is not because of
constalone. This declaration creates a box with contents that can be neither replaced nor modified because of two things:constprevents re-assignmentsIf you replaced the initial value
42with 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 yourconstbox can be modified because the value itself can be modified:This is what I meant when I said that no single construct in JavaScript can enforce complete immutability. Hope this helps!