let vs const vs var

TL;DR — Quick Comparison

What is var?

var is the original variable declaration keyword in JavaScript, predating the ES2015 specification by nearly two decades. It is function-scoped: a var declared anywhere inside a function is visible throughout that entire function, regardless of any nested blocks. At the top level of a script (outside any function), it becomes a property of the global object — window in browsers and global in Node.js.

var declarations are hoisted to the top of their scope and automatically initialised as undefined. This means you can reference a var variable before the line where it is written without throwing an error — you simply get undefined back, which is a common source of subtle bugs.

// Hoisting with var
console.log(count); // undefined — no error
var count = 5;
console.log(count); // 5

// var leaks out of blocks
if (true) {'{'}
  var leaked = 'oops';
{'}'}
console.log(leaked); // 'oops' — still accessible

What is let?

Introduced in ES2015, let declares a block-scoped variable. The variable only exists within the nearest enclosing block — typically a pair of curly braces. This makes behaviour far more intuitive: a loop counter declared with let does not leak into the surrounding function.

let is hoisted but is not initialised, leaving it in the Temporal Dead Zone (TDZ) from the start of the block until the declaration line is reached. Accessing the variable before that line throws a ReferenceError, making bugs visible rather than silently returning undefined.

// Block scoping with let
for (let i = 0; i < 3; i++) {'{'}
  setTimeout(() => console.log(i), 100);
{'}'}
// Logs: 0, 1, 2  (each iteration gets its own binding)

// TDZ in action
console.log(name); // ReferenceError — in TDZ
let name = 'Alice';

What is const?

Also introduced in ES2015, const behaves identically to let in terms of block scope and the Temporal Dead Zone. The sole difference is that a const binding cannot be reassigned after initialisation — attempting to do so throws a TypeError at runtime (or a compile-time error in TypeScript).

A common misconception is that const makes values immutable. It does not. It freezes the binding — the reference stored in the variable — not the underlying object or array. Properties of a const object can still be added, changed, or deleted.

const config = {'{'} debug: false {'}'};
config.debug = true;      // allowed — mutating the object
config = {'{'}{'}'};              // TypeError — reassigning the binding

const nums = [1, 2, 3];
nums.push(4);             // allowed — mutating the array
nums = [];                // TypeError

// Deep freeze requires extra work:
const frozen = Object.freeze({'{'} host: 'localhost' {'}'});
frozen.host = 'prod';     // silently ignored in sloppy mode
                          // TypeError in strict mode

Key Differences in Practice

Scope and the loop closure problem

The classic JavaScript interview problem involves a for loop with asynchronous callbacks. With var, all callbacks share one variable. With let, each iteration creates a fresh binding — the problem disappears entirely without needing an IIFE workaround.

Global pollution

Scripts loaded via <script> tags share the global scope. A top-level var declaration adds a property to window, making name collisions between libraries a real risk. let and const do not pollute the global object, even at the top level of a script — in a module context they are completely isolated.

Redeclaration

var allows you to declare the same variable name multiple times in the same scope without error — the second declaration is silently ignored. let and const throw a SyntaxError if you attempt to redeclare the same name in the same scope, which catches copy-paste mistakes early.

How Engineers Talk About let, const, and var

These are phrases you will hear in code reviews, stand-ups, and technical interviews at English-speaking companies.

• "Just use const by default and reach for let only when you genuinely need to reassign." A common code-review recommendation that signals awareness of modern best practices.
• "This closure captures the var — that's why all your callbacks fire with the same value." Diagnosing the classic loop-plus-async bug during a debugging session.
• "The TDZ is biting you here — you're reading the variable before its declaration." Explaining a ReferenceError caused by accessing a let or const binding too early.
• "const doesn't mean immutable — it just means you can't rebind the variable." Clarifying a widespread misconception during a code review or onboarding session.
• "We have the no-var ESLint rule enabled, so please migrate this to let or const." A pull-request comment asking a contributor to update legacy code to meet the project's linting standards.
• "Prefer const here — prefer-const will flag this in CI anyway." Pointing out that the ESLint rule will fail the build if a let is never reassigned.
• "var leaks out of the if block — that's a function-scoping thing." Explaining why a variable declared inside an if statement is still accessible outside it.
• "We use Object.freeze() on top of const for config objects we truly never want mutated." Describing a deliberate pattern to enforce actual immutability, not just binding stability.

Decision Guide — Which Keyword to Use

1. Default to const. Most bindings in well-written JavaScript do not need reassignment. Using const signals intent clearly and prevents accidental reassignment. It is the idiomatic choice in modern codebases and is enforced by ESLint's prefer-const rule.
2. Use let when you must reassign. Loop counters (for (let i = 0; ...)), accumulator variables, and state that changes during execution are natural candidates. Keep the scope as narrow as possible.
3. Avoid var in new code. Its function-scoping and hoisting quirks add cognitive overhead with no compensating benefit. Add no-var to your ESLint config to enforce this across the project.
4. When working with objects and arrays, const does not prevent mutation. If you need deep immutability — for example, a shared configuration object — combine const with Object.freeze(), use TypeScript's readonly modifier, or reach for a library such as Immer.
5. In legacy code, leave var alone unless refactoring. Blindly replacing var with let/const in untested legacy code can introduce subtle behaviour changes due to scope differences. Refactor deliberately, with tests in place.

Relevant ESLint Rules

These rules appear in most professional JavaScript/TypeScript projects:

// .eslintrc or eslint.config.js
{"{"}
  "rules": {"{"}
    "no-var": "error",           // disallow var entirely
    "prefer-const": "error",     // require const when let is never reassigned
    "no-use-before-define": "error", // catches TDZ access and hoisting bugs
    "no-inner-declarations": "error" // disallows var inside blocks
  {"}"}
{"}"}

Popular configurations — Airbnb, StandardJS, and eslint:recommended extended with @typescript-eslint — enable no-var and prefer-const by default. These rules are effectively zero-cost: they run at build time and catch entire categories of bugs before code reaches production.

Related Comparisons

If you are exploring JavaScript and TypeScript concepts further, these comparisons cover closely related decisions:

• TypeScript vs JavaScript — How TypeScript's readonly keyword, type inference, and strict null checks complement (and often replace) the discipline enforced by const alone.
• git merge vs rebase — Another foundational decision where understanding the underlying model (like scope rules in JS) prevents entire categories of mistakes.
• SQL vs NoSQL — When your JavaScript application's data layer needs the same kind of deliberate, upfront choice.