I don't agree with this style.<p>`var` is broken. Don't try to find a use-case for it. Just don't use it.<p>It would be nicer to have real, deep immutability, but `const` isn't it. Therefore, use it for what it actually is, not what you wish it was. If you don't intend to reassign a reference, then mark the reference constant. That's it.<p>It may be surprising, but it's quite easy to write JS where almost every declaration is `const`. When every mundane variable is `const`, then the more complex initializations/data flows/accumulators really requiring `let` stand out, which is very useful for reviewing code ("let" = "warning: there may be an `else` or missing `switch` case that will leave that undefined").<p>Because `const` requires to be initialized at the time of definition, you know the variable is valid for its entire lifetime. When you find its value was wrong, there's only one place where the value could have come from (you don't need to comb the function to look for reassignments).
Why not use `const` as default? I would argue that using `let` instead is a premature optimization of readability.<p>It's easier to reason about a variable if you know it will always be one value—even if the value may be mutated (which is unfortunate).<p>`const` is a simpler construct. It has less rules and I would always suggest that using `let` will introduce complexity that only needs to be there when you can identify a genuine need to re-assign a value to your variable.<p>That said, I enjoyed the post. It's a good read!
const conveys additional information. It says "this name will not be rebound," not just to the reader, but to the machine interpreting this as well.<p>As a reader, I know that after reading a const line I don't have to check if someone rebinds this name before each use site -- it's impossible.<p>Interpreters and static analysis tools use this information to stop you when you write a piece of code that rebinds the name, asking "did you really mean to do that? You said you wouldn't."
To be honest, I've been following the rule of using capital letters for things that should remain 'constant'. If everyone working on the project knows that, it works like a charm, never had any issues with it. But it's nice to have const now. So, I do see value in the const feature even if it doesn't protect me against a commit by the devil himself who changes the content of const objects.<p>Long story short: If you want to be annoyed about this feature, then more power to you. I won't be.
> I think the likelihood is that a developer who needs to change a variable and gets a const-thrown error about it will probably just change the const to let and go on about their business.<p>If this is the core argument to not using 'const', then you are out of luck trying to enforce any coding style. I might as well just delete any code that doesn't make sense.
One advantage const can bring (at least when used with primitives or frozen values) can come from JS IDEs: if they detect a value is const, they can report its value when hovering the variable name, in a static way.<p>That's what Java IDEs do with static final variables.
> To most developers, it means that your LUCKY_NUMBERS will always be 12, 19, and 42.<p>Is that really true? I would assume the opposite. Most developers have used Java or C# or any of the other languages that have similar reference semantics. I would agree if you qualified that with "beginner".