JS let vs const: An Advanced Memory Deep Dive

Most tutorials cover let and const at the surface level: let allows reassignment, const does not. This article goes deeper — into how the temporal dead zone actually works, what const really guarantees (and what it does not), how engines can use const as an optimization hint, and practical guidelines for choosing between them.

What let and const Actually Guarantee

javascript

let x = 1;
x = 2; // ✓ reassignment allowed
 
const y = 1;
y = 2; // ❌ TypeError: Assignment to constant variable.
 
// const with objects — the BINDING is constant, not the value
const obj = { a: 1 };
obj.a = 99;   // ✓ modifying the object — allowed
obj.b = 100;  // ✓ adding properties — allowed
obj = {};     // ❌ reassigning the variable — TypeError
 
const arr = [1, 2, 3];
arr.push(4);  // ✓ mutating the array — allowed
arr = [];     // ❌ reassigning — TypeError

const means: this variable binding will not be reassigned. It says nothing about whether the value it points to can be mutated.

The Temporal Dead Zone (TDZ) — What Actually Happens

Both let and const are hoisted to the top of their block scope but are NOT initialized until the declaration line is reached. The gap between hoisting and initialization is the Temporal Dead Zone:

javascript

console.log(x); // ❌ ReferenceError: Cannot access 'x' before initialization
let x = 5;
console.log(x); // 5
 
// This differs from var:
console.log(v); // undefined — var is hoisted AND initialized to undefined
var v = 5;

What the TDZ Looks Like in Engine Implementation

The JavaScript engine:

1. Scans the block scope for all let/const declarations
2. Allocates storage for them but marks them as "uninitialized"
3. Any read or write to an uninitialized binding throws a ReferenceError
4. When execution reaches the declaration line, the binding transitions to "initialized"

javascript

{
  // TDZ for message starts here (hoisted but uninitialized)
  console.log(message); // ❌ ReferenceError — in TDZ
  const message = "Hello"; // TDZ ends here — now initialized
  console.log(message); // "Hello" ✓
}
// message does not exist here — block scoped

The TDZ exists for let and const, not var. This is why you get a ReferenceError (not undefined) for pre-initialization access — it is a signal that the code has a likely bug.

Block Scope vs Function Scope

var is function-scoped; let and const are block-scoped (any {}):

javascript

function scopeDemo() {
  if (true) {
    var  funcScoped = "visible outside if";
    let  blockScoped = "only inside if";
    const alsoBlock = "only inside if";
  }
  console.log(funcScoped);  // "visible outside if" ✓
  console.log(blockScoped); // ❌ ReferenceError
}
 
// Block scope in loops — critical for closures
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100); // 3, 3, 3 — shared var i
}
 
for (let j = 0; j < 3; j++) {
  setTimeout(() => console.log(j), 100); // 0, 1, 2 — new let j per iteration
}

The let loop behavior is often cited as the most practically important difference from var. Each loop iteration creates a new binding for let — meaning closures capture different variables.

Memory Implications: const as an Engine Hint

When you declare a variable with const, you signal to the JavaScript engine that the binding will not change. Modern engines like V8 can use this information for optimizations:

1. No need to check for rebinding: The engine can skip the reassignment check at runtime
2. Inline caching benefits: If a const holds an object, the engine may be more confident about the object's shape not changing (combined with object shape stability rules)
3. Dead code elimination: If the engine knows a const is a specific primitive at compile time, it can sometimes inline the value

javascript

// Engine potentially more confident about this:
const PI = 3.14159;
function circleArea(r) { return PI * r * r; }
 
// Than this (must re-check PI may have been reassigned):
let pi = 3.14159;
function circleArea2(r) { return pi * r * r; }

Modern engines are sophisticated enough that this difference is often negligible in practice — but it is the intent signaling that matters for code readability and maintainability.

Object.freeze — Actual Immutability

To make the value immutable (not just the binding), use Object.freeze():

javascript

const config = Object.freeze({
  apiUrl: "https://api.example.com",
  timeout: 5000,
  maxRetries: 3,
});
 
config.timeout = 9999; // Silently fails (non-strict) or throws (strict)
config.newKey = "value"; // Ignored
console.log(config.timeout); // 5000 — unchanged
 
// Note: freeze is shallow
const nested = Object.freeze({
  outer: "frozen",
  inner: { value: 1 }, // inner object is NOT frozen
});
nested.inner.value = 99; // ✓ — inner object was not frozen

For deep immutability, you need recursive freeze or an immutability library.

Comparison Table

When to Use Each

Use const by default — it communicates that you do not intend to reassign this variable. This is the clearest signal to both the engine and fellow developers.

Use let when the variable value needs to be updated:

javascript

// let — reassigned in loop or accumulation
let total = 0;
for (const item of cart) {
  total += item.price; // Reassignment required
}
 
let currentUser = null;
currentUser = await fetchUser(); // Reassignment required

Never use var in modern JavaScript unless maintaining legacy code. var's function scope and hoisting to undefined are sources of bugs.