People (more or less) can’t use another language if they’re targeting the browser.

Also, in general, using the most limited constructs that fit your use case makes a tonne of sense for code cleanliness, in any language. For example, in a language supporting private/protected/public properties and methods, you should always default to private, as that’s most limited and easiest to reason about. Then make it more public as necessary. Same goes for const vs. let - const is more limited, it’s a better default choice, only use let if you actually need to re-assign it. Using const means there’s one less thing for readers of the code to worry about, it’s a variable that CAN’T be reassigned, the same way you don’t have to worry about a private method being called externally.

This is, essentially, the “principle of least power.”

The problem is that, when prototyping and iterating a design I often don't know in advance what should be private or const and what shouldn't be. And when interactively experimenting in the DevTools console I often want to redefine `const shadowMapSize=1024` to `shadowMapSize=2048` but const breaks interactive console redefinition. I have to save the js file to disk and edit shadowMapSize there, then reload the code. This is the workflow for a static language like C++, not a dynamic language like Lisp or JavaScript.

This seems like a realllly weak reason to write less maintainable code (harder than it needs to be for future readers to reason about). For workflows like this, you can easily use let/var while prototyping. Then once you’re done and are cleaning up the code, writing tests, etc., switch to const if the reference is never re-assigned. It’s the same in every language - when prototyping, go wild with god functions, mutable state, public everything, whatever, but clean it up and make it readable/maintained before it gets merged to master.

Also, if you’re talking about leaving mutability like this in the code long term, this really only applies to GLOBAL mutable state, and global mutable state is a terrible thing for code maintainability in any language. If it’s not global, you can’t fiddle with it later in the console anyways. Littering your program with global mutable state just because “someday, someone may want to fiddle with this in the console, and this makes that slightly easier”, that’s just not a reasonable argument.

Immutable references, mutable data structures.

You're welcome to go use another language that doesn't have a formal spec, if you're so inclined to disagree with what the spec for this one says.

The keyword instructs the human to immediately unassign any mental overhead reserved for tracking changes to the value while `let` or `var` indicates that further digestion is required to determine potential. I see some value in that. Stop using `const` for declaring named functions, though.

Your efforts are better spent contributing upstream: https://github.com/eslint/eslint/blob/master/docs/rules/pref...

Could you explain what you think an "actual need" for const looks like?

Well, the thing is, if your answer is "never" then I'm less inclined to agree with you. I think "don't use it ever" is a much weaker argument than "here's where you should and shouldn't use it".

Why? What's the problem?

const improves readability, and the ability to reason about code. It lessens the need to exhaustively scan the code looking for other assignments to the variable.

You should focus less on constraining yourself to arbitrary ideologies and focus more on writing good code that’s easier to maintain and understand.

Could you explain why? I don’t really know JS.

Yes but why do you consider that bad?

It’s the same behaviour in many other languages.

Why would rebinding variables ever be a good thing?

Isn't that literally the same as java or a const pointer in c/c++?

const fixed the pointer but don't prevent user change the value in the storage it point to.

There are two possibilities in C++. I am not sure what the situation is in Java.

It is possible to define a pointer to an object whose contents may not be changed. This is done with ‘const * type object’.

If you want a pointer whose value must not change, but do not care about the contents of the pointed to object, you would write ‘type * const object’.

You ought to have mentioned that pointers of the latter type are quite rare in C. A mention of const pointer practically always means a pointer-to-const: a pointer you can't write through. Often you can still "re-bind" such pointer to another object – in both ways the polar opposite of JS const.

Of course, in C++ there are const references as well, and in this case const also means you can't modify the referenced object (in any case in C++ you can never re-bind a reference).

Sure, this describes the problems with JS's const, but doesn't really describe why it shouldn't be used?

Most JS people consider it perfectly fine to use it. It's a just a tool. A minority wants to make a storm in a cup of water because they read this[1]

[1] https://jamie.build/const

He’s an angry chap isn’t he?

If you ever feel compelled to google him, you may want to grab some popcorn first :)

Hmm, some good points there. I think I'll avoid const now.

I didn’t think any of these points were very strong.

const x = {immutableValue}

That tells me the thing is fully immutable. Whether it’s a global variable or not, that’s still nice to know when reading the code! Likewise:

let x = {immutableValue}

const x = {mutableValue}

These tell me different things. The first tells me I should look out for re-assignment, the second that I should look out for mutation of the value.

In contrast, this:

let x = {mutableValue}

Clearly has the most cognitive load. Anything could happen with this. If it’s a bigger, more complex function/whatever, “what happens to x, it could be anything” is just one more thing to fit in my head as I try to figure out what this code does. Enough little uncertainties like this, and I have to give up understanding by reading entirely, and resort to a debugger. Had the author limited the scope of what was possible, it’d be a bit easier to understand, with really no drawbacks. It’s not the end of the world, but “small, simple, easy thing I can do to make the code easier to understand for future readers” ... why not do that?

Really, I just have a somewhat FP bias, and I'd really enjoy it if const was actually immutable, since it'd be a nice concise way of expressing that. It's just not as useful as you'd think given how often it seems to be used (by contrast I almost never see anyone actually making anything immutable in JS).

I like FP too, but most languages, including FP ones, have both mutable/immutable references and mutable/immutable values. And in JS, things like strings, numbers and booleans are immutable value, plus immutable.js is quite popular for immutable data structures, especially in React+Redux apps.

Ironically, I think your comment falls into the same cognitive trap as the const vs let thing: the always-use-let argument is usually that const does not mean immutable data structure and that fact is confusing, so you should let to signal that the data structure is mutable, even though what let really means is to make the binding mutable, not to indicate anything about the data structure it points to. The counter-argument - despite what it may seem - is not the opposite stance, but rather that because bindings and data structures are two different things, conflating the two is confusing.

Likewise, I'm saying that a minority is vocal because reading a rant from a OSS celebrity either reaffirms their preconceptions or sways them through aggressiveness (both of which are objectively true, as I have witnessed cases of both), but you're accusing me of projecting (presumably because you think that I'm making a claim about you personally - which is not true).

Consider that some of the words you use are weasel words ("overusing", "fad"), which, IMHO imply a tautology (i.e. "I think X, therefore X", as opposed to "The facts are X, therefore Y"). I originally said that the spec is clear about what const and let are. Implying that following the spec is a fad is needlessly derogatory and doesn't address the double standard with regards to the confusing-ness of const vs let.

There's a record & tuple proposal that would address this use case (currently served by tools such as Immer):

  const foo = #{};
  foo = 42; //not allowed
  foo.bar = 'baz'; //not allowed

https://2ality.com/2020/05/records-tuples-first-look.html

const is useful when multiple part of a program might refer to the same object/value, blocking rebindings is what you need to keep all the references in sync.

You seem to be confusing const iwth the functionality of Object.seal() and Object.freeze(). While const only makes the reference immutable, with Object.freeze() you can actually make the data immutable. Once you got this, there is not problem with using const all the time.