<blockquote>
<code class="language-text">let</code>&nbsp;vs&nbsp;<code class="language-text">const</code>&nbsp;vs&nbsp;<code class="language-text">var</code>: Usually you want&nbsp;<code class="language-text">let</code>. If you want to forbid assignment to this variable, you can use&nbsp;<code class="language-text">const</code>. (Some codebases and coworkers are pedantic and force you to use&nbsp;<code class="language-text">const</code>&nbsp;when there is only one assignment.)
</blockquote>
This turned out to be very controversial, sparking conversations on Twitter and Reddit. It seems that the majority view (or at least, the most vocally expressed view) is that one should&nbsp;use&nbsp;<code class="language-text">const</code>&nbsp;wherever possible,&nbsp;only falling back to&nbsp;<code class="language-text">let</code>&nbsp;where necessary, as can be enforced with the&nbsp;<a href="https://eslint.org/docs/rules/prefer-const" target="_blank" rel="nofollow noopener noreferrer"><code class="language-text">prefer-const</code></a>&nbsp;ESLint rule.
In this post, I will briefly summarize some of the arguments and counter-arguments I&rsquo;ve encountered, as well as my personal conclusion on this topic.
<h2 id="why-prefer-const">Why&nbsp;<code class="language-text">prefer-const</code></h2>
<ul>
<li>One Way to Do It: It is mental overhead to have to choose between&nbsp;<code class="language-text">let</code>&nbsp;and&nbsp;<code class="language-text">const</code>&nbsp;every time. A rule like &ldquo;always use&nbsp;<code class="language-text">const</code>&nbsp;where it works&rdquo; lets you stop thinking about it and can be enforced by a linter.</li>
<li>Reassignments May Cause Bugs: In a longer function, it can be easy to miss when a variable is reassigned. This may cause bugs. Particularly in closures,&nbsp;<code class="language-text">const</code>&nbsp;gives you confidence you&rsquo;ll always &ldquo;see&rdquo; the same value.</li>
<li>Learning About Mutation: Folks new to JavaScript often get confused thinking&nbsp;<code class="language-text">const</code>&nbsp;implies immutability. However, one could argue that it&rsquo;s important to learn the difference between variable mutation and assignment anyway, and preferring&nbsp;<code class="language-text">const</code>&nbsp;forces you to confront this distinction early on.</li>
<li>Meaningless Assignments: Sometimes, an assignment doesn&rsquo;t make sense at all. For example, with React Hooks, the values you get from a Hook like&nbsp;<code class="language-text">useState</code>&nbsp;are more like parameters. They flow in one direction. Seeing an error on their assignment helps you learn earlier about the React data flow.</li>
<li>Performance Benefits: There are occasional claims that JavaScript engines could make code using&nbsp;<code class="language-text">const</code>&nbsp;run faster due to the knowledge the variable won&rsquo;t be reassigned.</li>
</ul>
<h2 id="why-not-prefer-const">Why Not&nbsp;<code class="language-text">prefer-const</code></h2>
<ul>
<li>Loss of Intent: If we force&nbsp;<code class="language-text">const</code>&nbsp;everywhere it can work, we lose the ability to communicate whether it was&nbsp;important&nbsp;for something to not be reassigned.</li>
<li>Confusion with Immutability: In every discussion about why you should prefer&nbsp;<code class="language-text">const</code>, someone always confuses with immutability. This is unsurprising, as both assignment and mutation use the same&nbsp;<code class="language-text">=</code>&nbsp;operator. In response, people are usually told that they should &ldquo;just learn the language&rdquo;. However, the counter-argument is that if a feature that prevents mostly beginner mistakes is confusing to beginners, it isn&rsquo;t very helpful. And unfortunately, it doesn&rsquo;t help prevent mutation mistakes which span across modules and affect everyone.</li>
<li>Pressure to Avoid Redeclaring: A&nbsp;<code class="language-text">const</code>-first codebase creates a pressure to not use&nbsp;<code class="language-text">let</code>&nbsp;for conditionally assigned variables. For example, you might write&nbsp;<code class="language-text">const a = cond ? b : c</code>&nbsp;instead of an&nbsp;<code class="language-text">if</code>&nbsp;condition, even if both&nbsp;<code class="language-text">b</code>&nbsp;and&nbsp;<code class="language-text">c</code>&nbsp;branches are convoluted and giving them explicit names is awkward.</li>
<li>Reassignments May Not Cause Bugs: There are three common cases when reassignments cause bugs: when the scope is very large (such as module scope or huge functions), when the value is a parameter (so it&rsquo;s unexpected that it would be equal to something other than what was passed), and when a variable is used in a nested function. However, in many codebases most variables won&rsquo;t satisfy either of those cases, and parameters can&rsquo;t be marked as constant at all.</li>
<li>No Performance Benefits: It is my understanding that the engines are already aware of which variables are only assigned once &mdash; even if you use&nbsp;<code class="language-text">var</code>&nbsp;or&nbsp;<code class="language-text">let</code>. If we insist on speculating, we could just as well speculate that extra checks can&nbsp;create&nbsp;performance cost rather than reduce it. But really, engines are smart.</li>
</ul>
<h2 id="my-conclusion">My Conclusion</h2>
I don&rsquo;t care.
I would use whatever convention already exists in the codebase.
If you care, use a linter that automates checking and fixing this so that changing&nbsp;<code class="language-text">let</code>&nbsp;to&nbsp;<code class="language-text">const</code>&nbsp;doesn&rsquo;t become a delay in code review.
Finally, remember that linters exist to serve&nbsp;you. If a linter rule annoys you and your team, delete it. It may not be worth it. Learn from your own mistakes.

On let vs const

So I guess I&rsquo;ll say it. The way npm audit works is broken. Its rollout as a default after every npm install was rushed, inconsiderate, and inadequate for the front-end tooling. Have you heard the story about the boy who cried wolf? Spoiler alert: the wolf eats the sheep. If we don&rsquo;t want our sheep to be eaten, we need better tools. As of today, npm audit is a stain on the entire npm ecosystem. The best time to fix it was before rolling it out as a default. The next best time to fix it is now.

Nikos Kechris

Software Developer at XM - trading.com

Recent Blogs

On let vs const

npm audit: Broken by Design, The way npm audit works is broken.