let, const, var and the Temporal Dead Zone

Concept

Lesson 3 gave you the headline: var, let and const are all hoisted, and the difference is what happens next — var starts as undefined, let/const start locked in the Temporal Dead Zone (TDZ). This lesson is the full picture. Every axis on which the three keywords differ, in one grid. Function scope versus block scope, including the place where it matters most: loops. Exactly which lines the TDZ covers, why it is called temporal rather than positional, and the two places it hides where you would not expect it. Then the parts that confuse even experienced developers: redeclaration, errors that stop your whole file before a single line runs, the five distinct error messages, and the one real exception to “typeof is always safe”.

Key Words In Plain English

Short definitions first, so every later section is easier to read.

• Variable is a named box in memory that holds a value. let age = 7 makes a box called age that holds 7.
• Binding is the link between a name and its box. A variable is really a binding: the name age points to a value.
• Scope is the part of the code where a name can be used. Outside its scope, the name does not exist.
• Block is any code inside a pair of curly braces { }, for example the body of an if or a for.
• Hoisting is the engine reserving memory for declarations before it runs any line of the code. It does not move your code. It only means the names are known in advance.
• Initialise means give a binding its first value. Until then it is empty (var gives undefined) or locked (let/const).
• Temporal Dead Zone (TDZ) is the period of time between a let/const name being reserved and its declaration line running. In that period the name exists but reading or writing it throws an error.
• Shadowing is when an inner scope declares a name that already exists in an outer scope. Inside, the inner one hides the outer one.
• Parsing is the engine reading your source text and checking that it is valid JavaScript, before anything runs. Runtime is the time when the code actually runs, line by line.
• SyntaxError is an error for text that is not valid JavaScript. It is found while parsing. ReferenceError is an error for using a name that cannot be used right now. TypeError is an error for doing something a value does not allow, such as changing a const. These two are found at runtime.
• typeof is an operator that returns the type of a value as a string, such as "number". For a name that was never declared it returns "undefined" and does not throw.
• Closure is a function that remembers the variables from the place where it was created, even after that place has finished running.
• Primitive is a simple value that cannot be changed in place: a number, string, boolean, undefined, null, symbol or bigint. An object (including arrays) is a value with properties that can be changed.
• Object.freeze is a built-in function that stops an object from getting new, changed or removed properties. It only protects the top level.

Why This Matters

• “Which keyword should I use?” is answered properly only once you can see all the differences at once — scope, initial value, reassignment, redeclaration and the global object — rather than the one or two you happen to remember.
• The loop case (for (var i…) versus for (let i…)) is behind the single most famous JavaScript interview question, which Lesson 11 traces in full. This lesson gives you the memory picture it depends on.
• Redeclaration bugs are common when refactoring — knowing exactly which combinations throw and which don't saves real debugging time.
• Understanding that some errors are caught before your code even starts running explains why “but the console.log above the error never even printed” happens.
• The five distinct error types are a favourite interview drill — knowing which one applies to which mistake proves real understanding, not memorized keywords.
• The typeof TDZ exception is a real pitfall that surprises even experienced developers.

The Blueprint vs. The Locked Room — An Analogy

The Three Keywords Side By Side

Before going deep on any one row, here is the whole table. Read it top to bottom once now; the rest of the lesson explains the rows that need explaining.

Three things to notice. First, the hoisting row is identical — the engine reserves a slot for all three in the memory phase (Lesson 1). Second, the differences split cleanly into two families: var on one side, let/const on the other, with const adding exactly two extra rules on top of let (must initialise, cannot reassign). Third, the last row is the mechanism behind several of the others — let/const live in a private record the engine controls directly (Lesson 3), which is what makes a “locked” state possible at all.

Function Scope vs. Block Scope — And What Loops Do

var is function-scoped: it belongs to the nearest enclosing function (or to Global if there is none), and it ignores every other pair of braces on the way. let and const are block-scoped: they belong to the nearest enclosing { } of any kind — if, for, while, a bare block, a function body.

function checkIn() {
  if (true) {
    var floor = 3;            // belongs to checkIn, not to the if
    let wing = "north";       // belongs to the if block only
    const suite = false;      // belongs to the if block only
  }
  console.log(floor);         // 3
  console.log(typeof wing);   // "undefined" — gone with the block
}

Inside checkIn, floor is hoisted to the function's own memory during the memory phase, exactly as if it had been written on the first line of the function — the if braces are invisible to it. wing and suite are created when the block is entered and destroyed when it closes; by line 8 they do not exist anywhere in the scope chain (Lesson 7).

The place this matters most is a for loop, because a loop is a block that runs many times:

for (var i = 0; i < 3; i++) {
  console.log(i);
}
console.log(i); // 3 — leaked out of the loop

for (let i = 0; i < 3; i++) {
  console.log(i);
}
console.log(i); // ReferenceError: i is not defined

The visible difference is the last line. The important difference is invisible: with var there is one i for the whole loop, mutated three times. With let, the engine creates a fresh binding for every iteration — three separate slots that happen to share a name — and throws them all away when the loop ends.

1for (var i = 0; i < 3; i++) {
2  console.log(i);
3}
4console.log(i); // 3

1for (let i = 0; i < 3; i++) {
2  console.log(i);
3}
4console.log(i); // ReferenceError

The TDZ, Precisely: Where It Starts And Where It Ends

“Before the declaration” is the informal description. The precise one has two ends:

• It starts at the top of the enclosing scope — the opening brace of the block (or the first line of the function or file) — not at the line above the declaration. Every line of the scope that comes before the declaration is in the zone.
• It ends when the declaration is evaluated — when execution actually reaches and runs the let/const line. For let with no initialiser, that moment sets the binding to undefined: unlocked, merely empty, readable without error.

function checkIn() {
  // TDZ for roomNumber starts here — the top of the scope
  console.log(typeof roomNumber); // ReferenceError
  let roomNumber;                  // ← declaration evaluated: TDZ ends
  console.log(roomNumber);         // undefined — unlocked, just empty
  roomNumber = 101;
}

1·function checkIn() {
2🔒 dead zone  // TDZ for roomNumber starts here — the top of the scope
3🔒 dead zone  console.log(typeof roomNumber); // ReferenceError
4🔒 dead zone  helper();                        // ReferenceError if helper reads it
5unlock  let roomNumber;                  // ← declaration evaluated: TDZ ends
6usable  console.log(roomNumber);         // undefined — unlocked, just empty
7usable  roomNumber = 101;
8·}

Line 4 (let roomNumber;) is the detail people miss. let roomNumber; is not “still uninitialised” — evaluating the declaration is the initialisation, to undefined. After that line, roomNumber behaves like any empty variable. The lock is tied to the declaration being reached, not to a value being provided.

Why “Temporal” — It Is About Time, Not Position

The name is precise. The dead zone is a stretch of time during execution — from the scope being entered until the declaration runs — not a stretch of lines in the file. The cleanest proof is a function that reads the variable, written above the declaration both times, called twice:

function readRoom() {
  return roomNumber; // written ABOVE the let, both times
}

readRoom();          // ① ReferenceError — called before line 6 has run
let roomNumber = 101;
readRoom();          // ② 101 — same function, called after line 6 ran

1function readRoom() {
2  return roomNumber; // written ABOVE the let, both times
3}
4 
5readRoom();          // ① called before line 6 runs
6let roomNumber = 101;
7readRoom();          // ② called after line 6 ran

The TDZ In Disguise: Shadowing And Default Parameters

Two places the TDZ appears where people do not expect a declaration to matter at all.

Shadowing creates a fresh TDZ for the inner name

let roomNumber = 101;

{
  console.log(roomNumber); // ReferenceError — NOT 101
  let roomNumber = 202;    // this inner let shadows the outer one
}                          // …and its TDZ covers the whole block

The outer roomNumber is fully initialised — 101 is right there. But the block declares its own roomNumber (Lesson 7's shadowing), so inside the block every reference to that name resolves to the inner binding, which is locked from the block's opening brace until line 5. The lookup never climbs to the outer 101, because the nearest match wins — and the nearest match is in its dead zone. Reading line 4, you would swear it prints 101. It throws.

Default parameters are evaluated left to right, in their own scope

function book(nights = stay, stay = 1) {
  return nights * stay;
}
book();      // ReferenceError: Cannot access 'stay' before initialization
book(2);     // 2 — nights was given, so `stay` is never read early

Parameters with defaults behave like a sequence of let declarations, evaluated in order. When book() is called with no arguments, the engine evaluates nights = stay first — and stay, one position to the right, is still in its TDZ. Give nights a value and its default expression is never evaluated, so stay is never read early and nothing throws. A default may refer to any parameter to its left, never to its right.

Redeclaration: var Allows It, let And const Don't

var guestCount = 10;
var guestCount = 20; // totally fine — var allows redeclaring

let roomNumber = 101;
let roomNumber = 102; // SyntaxError: Identifier 'roomNumber' has already been declared

let discountRate = 5;
var discountRate = 10; // also SyntaxError — mixing var with an existing let in the same scope

The Parse-Time Twist: Why Some Errors Crash Everything

Before running a single line, the JS engine reads and checks your entire file first. A duplicate let declaration is caught right here, during this check — which means the error exists before execution has even started.

console.log("This never prints — not even this line!");
let x = 1;
let x = 2; // SyntaxError: Identifier 'x' has already been declared

Compare that with a TDZ violation, which is a genuine runtime error:

console.log("This DOES print completely fine");
console.log(y); // ReferenceError: Cannot access 'y' before initialization
let y = 1;

1console.log("This never prints");
2let x = 1;
3let x = 2; // SyntaxError

1console.log("This DOES print");
2console.log(y); // ReferenceError
3let y = 1;

The Five Error Types — Full Taxonomy

The typeof Exception: TDZ Breaks The Safety Net

Lesson 6 taught you that typeof is always safe — it never throws, even on a name that was never declared. That rule has exactly one exception, and it's the TDZ:

console.log(typeof unicornVariable); // "undefined" — safe, never declared anywhere

console.log(typeof discountRate);    // ReferenceError! — even typeof can't rescue a TDZ access
let discountRate = 10;

1console.log(typeof unicornVariable); // "undefined"
2 
3console.log(typeof discountRate);    // ReferenceError!
4let discountRate = 10;

const: A Frozen Binding, Not A Frozen Value

const is let plus two rules: the declaration must carry an initialiser (otherwise a SyntaxError at parse time — there would never be a moment to give it a value), and the binding can never be reassigned (a TypeError at runtime). Both rules are about the binding — the arrow from the name to the value. Neither says anything about the value at the other end of the arrow.

const guest = { name: "Aditi", room: 101 };

guest.room = 102;              // fine — the object changed, the binding did not
guest = { name: "Rahul" };     // TypeError: Assignment to constant variable.

const frozen = Object.freeze({ name: "Aditi", room: 101 });
frozen.room = 102;             // silently ignored (throws in strict mode)
console.log(frozen.room);      // 101

For primitives (numbers, strings, booleans) the distinction is invisible, because a primitive cannot be changed in place — the only way to “change” it is to re-point the binding, which const forbids. For objects and arrays the distinction is everything: guest.room = 102 reaches through the arrow and edits the object; the arrow itself is untouched. If you want the object frozen too, that is a separate, explicit request — Object.freeze — and it is shallow: nested objects inside remain mutable.

Minimizing Your Own TDZ Window — And Which Keyword To Use

The TDZ exists for every let/const from the top of its scope until its declaration line runs. You can't remove it, but you can make it as short as possible:

• Declare variables as close as possible to the top of the scope they belong to.
• Avoid deeply separating a variable's declaration from its first real use.
• Prefer const by default, use let only when reassignment is genuinely needed, and avoid var entirely in new code — this alone sidesteps almost every mistake in this lesson.

Real Example — Traced Line By Line

function checkIn() {
  console.log(typeof roomReady); // ReferenceError — TDZ, not "undefined"
  let roomReady = true;
  console.log(roomReady);        // true

  let roomReady = false;         // SyntaxError, caught before checkIn() even runs
}
checkIn();

1function checkIn() {
2  console.log(typeof roomReady);
3  let roomReady = true;
4  console.log(roomReady);
5 
6  let roomReady = false; // duplicate
7}
8checkIn();

1. File is parsed first

   The engine reads through checkIn's body ahead of time and finds two let roomReady declarations in the same scope — a SyntaxError is raised immediately.

2. Nothing inside checkIn ever runs

   Not the first console.log, not the assignment, not the second console.log — the whole function body is invalid before checkIn() is ever called.

3. Fixing it

   Remove the duplicate declaration, and now the first line correctly throws a different error — a TDZ ReferenceError from the typeof pitfall — since roomReady hasn't been declared yet at that point.

See It Live — Console & DevTools

1. Open the console

   Any page → DevTools (F12) → Console tab.

2. Trigger a SyntaxError

   consoleCopy

   let a = 1;
   let a = 2; // SyntaxError — paste both lines together as one snippet

3. Trigger a TDZ ReferenceError

   consoleCopy

   console.log(typeof b); // ReferenceError
   let b = 1;

4. Compare with an undeclared name

   consoleCopy

   console.log(typeof totallyUnknown); // "undefined" — no error at all

5. Watch the TDZ in the Scope panel

   scope-panel.jsCopy

   function checkIn() {
     debugger;            // paused here, roomNumber is in the TDZ
     let roomNumber = 101;
     debugger;            // paused here, it is 101
   }
   checkIn();

   At the first pause, open Scope → Local: Chrome lists roomNumber already, with the value <value unavailable> — its way of showing a binding that exists but is locked. Resume to the second pause and the same entry reads 101. That is the TDZ, rendered by the engine itself.

6. Count the loop slots

   consoleCopy

   for (let i = 0; i < 3; i++) { debugger; }

   Each time it pauses, Scope → Block shows an i — and stepping to the next iteration shows a new Block scope, not the same one with a bigger number. Swap let for var and the Block scope disappears: i now sits in Local (or Global) for the whole loop.

7. Confirm the difference side by side

   consoleCopy

   console.log("hello");
   let a = 1;
   let a = 2;

   Paste this as one snippet. Only the SyntaxError appears and hello never prints. That is proof the error was caught before any line ran. Now remove the last line and paste again: hello prints.

Common Misconceptions

Interview Questions