Check out a free preview of the full ES6: The Right Parts course:
The "Const" Lesson is part of the full, ES6: The Right Parts course featured in this preview video. Here's what you'd learn in this lesson:

The behavior of the const keyword in JavaScript varies slightly from other languages. Const prevents a variable from being reassigned. However, complex data types like arrays and objects could still be mutated. Kyle works through a couple examples using the const keyword to reinforce its behavior.

Get Unlimited Access Now

Transcript from the "Const" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kyle Simpson: So I think you ought to make explicit blocks, not use implicit blocks. That's my own personal take on that. By the way let declarations can obviously declare more than one so you could say y = x * 3 or whatever you want to do. Okay so that's the let keyword.

[00:00:20] In addition to the var keyword. Any more questions on let before we move on to const? Const is a another block scoping operator that was added to the language. So in this particular case you could use it in the place where you had a let. It's a block scoping declarator.

[00:00:42] So it's kinda like a cousin to let in that sense. But what const does is something a little bit different. And it's probably something a little bit different than what you might normally assume so let me just ask for a moment. What do you all think const x = 2 is actually creating?

[00:01:00] Anyone?
>> Speaker 2: Keeps you from reassigning x to something new.
>> Kyle Simpson: Okay, good answer. Anybody else have a different answer?
>> Speaker 3: I think just conceptually or under the covers, what is it?
>> Kyle Simpson: You tell me.
>> Speaker 3: I would assume it's making a getter that has no say.
>> Kyle Simpson: I'm not necessarily talking about implementations.

[00:01:20] I guess what I'm really asking is what's the behavior in our code, what are we creating?
>> Speaker 3: Mutable value that if you signed again-
>> Kyle Simpson: So some people say mutable values, okay. So we've heard can't be reassigned. We've heard immutable values. Anybody else have a different explanation for when you tell somebody about the const keyword, what are you usually saying?

[00:01:41] You're usually telling somebody I'm creating a what?
>> Speaker 4: A constant.
>> Kyle Simpson: A constant, so what is a constant?
>> Speaker 5: Value doesn't change.
>> Kyle Simpson: A value that doesn't change. That's how a lot of people describe it okay? Only one of the answers that I've heard is actually accurate. All the other ones are well meaning in spirit but off banks in terms of what's really going on.

[00:02:03] So specifically, a constant is a variable that cannot be reassigned and has nothing to do with the value.
>> Kyle Simpson: But the problem is that word constant is always associated in our developer minds with the value. So when people hear the word constant, what they think is it's a value that doesn't change, it's a value that's immutable.

[00:02:23] That's what almost everybody says when you ask them that question, what is a constant? We almost always get that. But really what it is, as this gentleman said really what it is, is that a constant is a variable that can't be reassigned. So this confusion that I'm talking about is not new to JavaScript.

[00:02:41] The const keyword has been introduced in a whole bunch other languages before JavaScript and as Stack Overflow can prove to us, it's confused developers in every one of those communities as well. So much so that some languages actually had to add another keyword. Like Java added the final keyword to try to talk about value semantics.

[00:03:00] Because everybody kept thinking that const had to do with the value and it didn't. So they added final to say this value doesn't change anymore. Const is about assignment. So put it all simply, if I say something like const x = 3, it is true that 3 is an immutable value but has nothing to do with const.

[00:03:20] Because 3 is also an immutable value here, okay? What's different about this program is that x can't be reassigned, okay? To point that out even more specifically, if y is some array with values in it, y cannot be reassigned. If I say y = 2, that fails. If I say y equals some other array, that fails.

[00:03:49] Great but y is most definitely not pointing at an immutable value because I can say y

[0] = 42 and it's gonna work all day long because the value itself has nothing to do with the const keyword. It's just the assignment of it, okay? So there are some people.

[00:04:08] As a matter of fact, many people out there that are telling developers, what you should do is always declare your variables with const. And in certain cases, when it needs to be reassignable, change those to lets, and never use var. So they const, let, never use var. My advice is literally the inverse of that.

[00:04:29] var, use let where that's helpful. Every once in a while, maybe use const. Literally the inverse, okay? Because there's a whole bunch of places where the const keyword is going to confuse readers of your code that are not already familiar with the differences. They're gonna be confused into thinking this is a value that doesn't change.

[00:04:47] For example, some developer is gonna come along and they're gonna see this piece of code and then they're gonna see it pass in x. And they're gonna think to themselves, x doesn't change. I know x is still on array one two three. But is that the case? It's not the case because we passed in a reference to a mutable value and through absolutely can do something stupid like change the contents of that array and a reader of your code might be confused when they see the const keyword into not realizing that.

[00:05:18] So the const keyword has the potential to lead people down this path of being confused about the value semantic. And I'm not just saying that on my own, I'm saying we've got three decades of experience with other languages that say sometimes developers get confused. Is it learnable? Yes.

[00:05:34] Is it natural and instinctive and intuitive? Maybe not so much, okay? So the const keyword has this potential problem but what's its value benefit. The value benefit supposedly is that we're communicating which sounds exactly like something that be right up my alley. We are communicating when we write this line of code on the first line of our block, we are communicating that x will never be reassigned, okay?

[00:06:00] We'll get to that question in just one moment, just let me finish this thought real quick. We are communicating x will never be reassigned. But let me ask you a question. Let's imagine that this is inside of some blocks somewhere, okay? And there's some other code in this block.

[00:06:17] You've probably heard before, people tell you, stylistically, you should keep your functions in your blocks really small, okay? Most people tell you, if they're of that opinion, they'll tell you your block should never be more than maybe five lines, six, seven lines of code, right? They want you to keep things small.

[00:06:32] There are people that say, a whole function shouldn't be more than five lines. If it's more than five lines you split it out, right? We hear this all the time. It's nonsense but we hear it all the time, right? So let's go really crazy. And let's say that we wrote a ten line block of code.

[00:06:46] I mean I know that's just way out there in an outer space. But let's say we wrote a ten line block, and on the first line we said const x = and we're supposedly communicating to other developers. x is not gonna be reassigned. But let me ask you a question.

[00:07:01] Let's say that that block is within the program. We've got a million lines of code. How many lines of that code can affect the assignment of x?
>> Kyle Simpson: Is it a million? There's only nine other lines in that entire million line program that can actually change the assignment of x because it's block scoped.

[00:07:29] Even if we pass x somewhere. The code inside of foo cannot affect the assignment of x. Can affect the value, can't affect the assignment. So let me just summarize it this way, and then I'll get to the question. The const keyword is saying, I'm not going to reassign this variable in the next few lines of code.

[00:07:56] I prefer to communicate that by just simply not reassigning it in the next few lines of code. Because the const keyword, because of all the confusion potential doesn't actually help me with that communication. I just don't reassign it and then I've communicated I'm not gonna reassign it. But there's another problem here, which is that whole thing that values can go other places and get mutated, that's a big deal.

[00:08:17] Const doesn't help us with that. If you wanted to make sure that somebody couldn't change it, you don't need the const keyword, what you need is object.freeze That's been built in since ES5. That's not even an ES6 thing. Breaking news, seven years ago we got this utility called object.freeze.

[00:08:36] It makes that object at the shallow top level, it's a shallow freeze it makes it read only properties so in effect it is an immutable value, okay? Not a real immutable value in terms of performance but poor man's immutable value. So if I wanted to communicate to some developer that x is not gonna be changed by foo, I could just as easily do that with var x and I would say have less confusion potential with them if I use the const keyword.

[00:09:02] By saying object.phrase.