IMO the article's conclusion is wrong. We should indeed use `const`, and we should indeed use it to communicate. But the thing we should use it to communicate is different than what the article proposes.

We should use `const` to communicate that we don't intend to reassign or mutate the variable. And we should do that by default unless there's a compelling reason to do otherwise.

I know it can't be fully enforced, because JavaScript is designed for mutability of objects by default. But it is an implementation style that is almost always achievable in plain ES6 without too much trouble, and it makes more reliable software that's easier to reason about.

And in TypeScript you can at least pair it with Readonly<...>, though that unfortunately still isn't recursive

Nice plugin to make sure you never mutate: https://github.com/jonaskello/tslint-immutable/tree/master/t...

You can add a rule based on the name of the variable to allow mutating (e.g. naming it `mutableSomething`)

Interesting, but not really tractable if you have to manually add every single variable to the rules config.

The plugin allows pattern-based exceptions.

For example, if your rule excluded variables with a "mutable" prefix, you could name your variable mutableSomething and it will be automatically ignored by the linter

I think one important point that Dan and others miss is that `const` enforces a single-assignment style of variable naming that many find preferable. It makes it easier to read and forces people to provide more thoughtful names for their variables. I'm not saying that this behavior is enough to justify using `const` everywhere, but it should be weighed in any judgement about style.

I'm not sure what either link clarify.

The first link is someone confusing reassignment mutability with value mutability, a common beginner mistake when they read the byline of "const". It's like reading a rant about how { ...obj } only does a shallow clone and thus "doesn't do anything and we all know it" because you can still modify `obj` to modify the new object.

The second link, a tweet, gives no reasoning.

That's amazing. I was just scratching my head about const when I read the article, "so what's the purpose if I can change the value... but I guess I can't re-assign the variable with a new value .... that's it?"

I still found the article incredibly informative, sadly as someone still stuck working on legacy apps it falls into "...in some near future I'll take advantage of JavaScript new stuff"

> That's amazing. I was just scratching my head about const when I read the article, "so what's the purpose if I can change the value... but I guess I can't re-assign the variable with a new value .... that's it?"

If the value is a primitive, you can't change it. If the value's a reference you also can't change that, but of course you can modify whatever that points to.

Is that what's bugging people about this?

I believe so. I don't make a big issue out of it... but anything carrying the word const I expect it to be fully read-only with no "buts" in between throughout the whole execution of the program. I guess if they used "readonly" as C# it would make more sense?

If you're willing to add a build step to the project, Babel will let you use all the new features and compile down to whatever version you need.

Thanks, I've never checked out Babel. I will truly suggest that to my lead, seems something we can take advantage of.

Does JavaScript have value types where const might work the way the first author expects it to?

symbol/boolean/string/number are immutable and work how you'd expect with const because they are immutable. Unsure if that makes them "value types".

I think the article is a bit silly. Calling it "const" was a mistake but that's a naming issue. JS's "const" is the same as Java's "final," right? It communicates something useful.

In JS, I think of any reference to an object as a pointer, and the <pointer> is immutable even if its contents aren't; then everything in JS which can be considered a value which is immutable under const.

IMO it's not just a problem of const vs let, because it'll pop up again when you're trying to copy a JavaScript object, and it'll pop up again when someone has questions about garbage collection.

JavaScript not only has (a small set of) value types, it also has frozen objects.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I won't repeat the other comments, but I'll note that you can make the additional, uglier step to get the results the first author expects by (as suggested) treating the assignment as a pointer to the object and rendering the object immutable.

    const myObject = Object.freeze({
        myValue: "Something",
    });

The problem with that is `Object.freeze` doesn't act on nested objects, so you usually have to have some other method/macro to do that for you. You might be able to do that with decorators in TS.

It works on Object and Array types, but not on other primitive types. That part is frustrating. It would certainly be nice to have a single method for rendering any value immutable, whether it was the initial assignment or a built-in.

No. The only thing that makes const unique from let is that references declared as constants cannot be reassigned or else an error will be thrown. The exclusion only applies to the reference name itself and not to any of its properties as the article articulates.

I read a whole bunch of that tweet thread and got nothing out of it. What's wrong with const? Been using it for quite a while now, seems fine, no trouble. What am I missing?

The OP article is common knowledge and is a copy of a copy of a copy. Your first link, on the other hand, is the perfect recipe for my Friday afternoon. Cheers!

it's also wrong in the first sentence. there are at least 5 ways to define variables in js (edit: hint: globals)

Lol that first read is fantastic.

  const doesn't do shit and we all know it

Was a great intro, and absolutely true. Unfortunately I don't think this will catch on, although I agree with the author that it should.

I like the reassignment prevention.

I agree with Dan. I don't use var/const for much the same reason I don't use ==.

Those links are beautiful. It's nice knowing someone else out there has some sense. It makes me feel less alone.

But sadly the pedants won't let this go. The misuse of const is already documented as The Right Way, baked into libraries and live in production in millions of places. Sad but true.

I'd love to do some GitHub sleuthing and find the first few developers out there to publish a project that misused const in their code, so we could tar and feather them. Though obviously being some sort of fad or mass delusion, it wasn't entirely their fault.