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.