DEV Community

Confused by JavaScript's const? Me too!

Brian Rinaldi on June 21, 2019

The other day I had a little back and forth on Twitter around the concept of const in JavaScript. Kyle Simpson had pointed out a misunderstanding a...

Read full post

Austin S. Hemmelgarn • Jun 21 '19

Other than the readability aspect (which is indeed big), there are a few other bnefits to using const that many people don't think about:

It tells the JS engine that the reference won't change. This sounds useless, but it has the potential to allow for some optimizations that would not otherwise be possible. I'm not sure whether any of the big JS implementations actually take advantage of this or not, but it's still worth considering.
Some IDE's, as well as some code checking tools, can be configured to complain if they see an indentifier declared with const on the left side of an assignment expression, even if the assignment would be to a property of the referenced object.

Honestly, if I know for certain that something shouldn't change, I use const, period. Yes, it can lead to confusion, but that confusion is usually less significant than properly annotating that something shouldn't change.

George • Jun 21 '19 • Edited

You should check out Object.freeze if you want const to be immutable or Object.seal if you want const to just be a little bit mutable.

Brian Rinaldi • Jun 21 '19

Thanks. Yes, I didn't bring them up because I thought it might sidetrack the discussion of const a bit but if immutability really matters for what you are doing, then definitely.

George • Jun 21 '19

I had always assumed they were immutable, was shocked to find they weren't.

The immutability was the key reason I started to use them.

stereobooster • Jun 21 '19

The issue here is that there are 2 similar but different concepts: referential transparency (const) vs immutability (Object.freeze or even better recursive Object.freeze)

Jordan Kicklighter • Jun 22 '19

In practice, I do what Wes Bos had recommended in his ES6 course: use const for every single variable, and only change to let if I will need to change that variable's assignment.

Brian Rinaldi • Jun 22 '19

Thanks for the comment. I had received similar recommendations. A team that I worked with even had ESLint set to enforce using const for every variable where it wasn't reassigned - even objects that were mutated. This is where it caused me confusion and it was probably more common than actual primitive constants in the code. As a personal style preference, I would not choose to do that where I have the option.

Antti Pihlaja • Jun 22 '19

When seeing let, my first thought is why that's not const? Using let communicates: watch out, we are doing some weird stuff here. Usually it signals programming paradigm change.

For example, in react app, you need maybe one or two let variables for some special cases. It steps out quite bit in the middle of declarative functional code.

Simon Dell • Jun 26 '19 • Edited

The difference between consts which preserve value and consts which preserve references, reflects the difference between variables that get passed by value and those which get passed by reference.

When a variable holding a primitive value gets passed to a function, the value gets copied into function's parameters ("pass by value"). The function can make changes to the value without affecting the variable's value outside the function. This holds for variables declared with var, const or let. I see a symmetry between the value's immutability, when declared with const, and the pass-by-value rules.

var bar = 'bar'
const baz = 'baz'
let qux = 'qux'

function makeFoo(fromParam) {
  fromParam = 'foo'
  return fromParam
}
makeFoo(bar) // "foo"
bar // "bar"

makeFoo(baz) // "foo"
baz // "baz"

makeFoo(qux) // "foo"
qux // "qux"

When a variable holding a complex value (variations of Object) gets passed to a function, the function cannot change the reference (pass by reference), but it can change properties of the passed object. This reflects the mutability of complex consts.

I found this observation helped me cement my knowledge about which aspects of variables const protects.

Ken • Jun 22 '19

I think objects are referential (like a pointer in other languages) so the const is the reference to that object. At least that is what I tell myself so I can sleep at night 🤣

Eugene Karataev • Jun 22 '19

Yes, objects are passed by reference, but there are no pointers in JavaScript. We can't have direct access to memory addresses like in C language.
I wrote a mini-post describing how references in JS work with objects. By walking through a simple example, it shows that a variable can't reference another variable.

References in JavaScript

Eugene Karataev ・ May 7 ・ 1 min read

#javascript #frontend #programming #reference

PeterGabriel2 • Oct 29 '19

It is not important if language provides access to memory or not. Pointer is always address to some space occupied by data regardless of programming language.
If you will have one object and this object you will put into 500 arrays, you still have only one object on the same address (on the same pointer).
So we can say that even javascript has pointers/addresses.

Eugene Karataev • Oct 30 '19

I agree that under the hood there are pointers, memory allocation, e.t.c. I mean that JavaScript doesn't have syntax to work pointers directly and allocate/free memory like it's done in C or similar languages.

Yevhen Kozlov • Jun 21 '19 • Edited

quick search says that for Java final is also just about referencing(for immutability there is no modifier). say for C++ it's combined with sealing(but needs you to declare "change safe" methods as const too).

PeterGabriel2 • Oct 29 '19 • Edited

I am not confused by JS consts behaviour. It acts like it should be. The same way as most of programming languages. Actually I have never worked with language that behave differently.

And differences between let and var is about scope: stackoverflow.com/questions/762011...
If you don't know what to use then use let.

Cubicle Buddha • Jun 23 '19

Should you use const?

Yes! Absolutely! It’s all about immutability.

And if you’re using TypeScript you should consider additionally using the Readonly keyword to really drive it home.

Patrick R • Jun 24 '19

Thoughts on Immutable.js ? I like the idea of using it, but it sometimes makes things more verbose than they need to be

Michael De Abreu • Jun 25 '19

I could recommend that you use typescript instead. If you use readonly modifiers and const assertion you can have immutable code in development, and better performance in production.