Choosing how to better take advantage of ES6 const and let

Question

Disclaimer: I know that the question below might be seen as "asking for opinions" (so it'd be off-topic).
But it's not the case: I'm looking for pros and/or cons facts which should be took in account while thinking about that.

By chance I just read (from the excellent Exploring ES6) an excerpt focusing on const vs let vs var, where the conclusion states (bolding is mine):

Then we have two approaches:

1. Prefer const: const marks immutable bindings.
2. Prefer let: const marks immutable values.

I lean slightly in favor of #1, but #2 is fine, too.

What puzzles me is: this preference seems to be based on the deep technical significance of the resulting difference betweeen the two approaches, as if the author feels essentially concerned by how the code works at low level.

But I feel concerned also (and maybe first!) by the readability aspect: from this point of view, #2 seems better to make the code more semantically significant about what happens to the processed data.

But maybe I'm missing some advantages of the #1 choice...?

---

EDIT, taking advantage of the link proposed as duplicate: Why most of the time should I use const instead of let in javascript?

In fact the accepted answer to that question actually exposes things in such a way that it rather enforces me to my previous view, i.e. #2 is better than #1.

BTW I realized that my question was probably not as clear as it should, so here is a more detailed rewording:

• I'm quite aware of (AFAIK) all the technical differences between const and let, so my question doesn't ask for anything about that.
• The only point really involved by the choice between #1 and #2 lies in using const for any immutable object (though its content may be changed!) vs for frozen objects only.

It's there that I'm surprised the author prefers #1, since (from my point of view) it's rather misleading.
The most frequent way of using objects is that their content changes during the process, so reading const at its declaration level, if #1 is used:

• at best we don't know what is supposed to happen to it.
• at worst we may imagine that its content will never change, while it can!

In the other hand, choosing to use #2, we can trust that a const-declared object will not change (indeed apart from oversight and/or bug).

So to go back to my question: since the above reflexion seems to clearly lead to choose #2, I wonder what point I may have missed, which makes the author prefer #1.

Answer 1

To keep inline with your fact-seeking journey, I'll avoid stating opinions and describe my answer in objective, simple terms.

The author's preference is not based on "deep technical significance" because the significance is actually rather shallow: in short, the only difference between the two keywords is that a const variable cannot be reassigned, but a let variable can.

The intent of preference #1 is to use const in the specific manner in which it was defined, preventing pointing a variable at a new assignment.

The intent of preference #2 is to pretend (or act) like any RHS value initializing a const variable is immutable, which requires effort on the developers' part to know that and act accordingly.

A disadvantage of #2 is that it is introducing a convention for coding with const that is inconsistent with its actual function, so it's mainly a matter of coding standards and code maintenance. In other words, if a dev team dictates that const must only be used for immutable declarations, it will make the code easier to understand that such values should not be modified, but it's actually not the case that they cannot be modified. (If this convention was to be followed, it would make sense that const only be used for values that are actually immutable, e.g., using Object.freeze().)

The advantage of #1 is that you're using const as it was designed: you're treating such variables as if their assignment cannot be changed, not pretending const offers something that it does not provide (i.e., immutability), so there's no potential for developers to mistakenly modify the contents of a const object that they are supposed to pretend cannot be modified.