What exactly is the temporal dead zone in JavaScript, and when does a let or const binding enter and leave it?

## The three states of a binding Most mental models have two states for a variable: it exists, or it does not. JavaScript has three. 1. **Not declared** — no binding anywhere in the scope chain. Reading it throws `ReferenceError: x is not defined`. 2. **Declared and uninitialized** — the binding exists in an Environment Record but holds no value at all. Reading *or writing* it throws `ReferenceError: Cannot access 'x' before initialization`. 3. **Declared and initialized** — the binding holds a value, possibly `undefined`. State 2 is the temporal dead zone. `var` bindings skip it entirely: they go straight to state 3 with the value `undefined`. `let`, `const`, and `class` declarations pass through it. ## When the TDZ begins It begins at **scope instantiation** — the moment the engine enters the script, function body, or block and builds its Environment Record, before any statement of that scope runs. Every `let`, `const`, and `class` name declared anywhere in that scope gets a slot then, marked uninitialized. This is why a lexical declaration further down a block shadows an outer binding for the whole block: ```js const mode = 'outer'; { console.log(mode); // ReferenceError - the inner binding already shadows the outer one const mode = 'inner'; } ``` The outer `mode` is not reachable inside the block at all. The inner binding exists from the opening brace; it is just uninitialized. ## When the TDZ ends It ends when that binding's **declaration is evaluated** — specifically when the engine runs the LexicalBinding and calls InitializeBinding on the slot. Concretely: - `let x = compute();` — the initializer runs first, then the binding is initialized to its result. If `compute()` itself reads `x`, that read still throws. - `let x;` — no initializer, so the binding is initialized to `undefined` at that statement. Before it, reads throw; after it, reads give `undefined`. - `const x = 1;` — `const` without an initializer is a *SyntaxError*, so a `const` binding always leaves the TDZ holding a real value. - `class C {}` — the class binding is uninitialized until the class definition is evaluated, so `new C()` written above the class declaration throws. It ends **per binding**, not per scope. Two declarations in the same block leave the TDZ at two different moments. ## Temporal, not spatial The name is precise and worth defending in an interview: the zone is a stretch of *time*, not a region of *source text*. Code written above a declaration is not automatically doomed — it only fails if it *runs* before the declaration is evaluated. ```js function read() { return limit; } // written above the declaration let limit = 10; console.log(read()); // 10 - read() is called after limit is initialized ``` Move the call up one line and the same function throws: ```js function read() { return limit; } console.log(read()); // ReferenceError: Cannot access 'limit' before initialization let limit = 10; ``` The function body never changed. Only the moment of invocation did. This is exactly why the bug is confusing in real code: the throwing line is often nowhere near the declaration, and the same function works on a later call. ## Writes throw too The TDZ is not read-only protection. Assigning to the binding before its declaration throws just as hard: ```js try { count = 5; } catch (e) { console.log(e.constructor.name); } // ReferenceError let count; ``` That matters because it rules out the workaround people reach for first — "I'll just assign it earlier." ## Why the design is deliberate The TDZ exists so that `const` can mean something. If lexical bindings were pre-initialized to `undefined` like `var`, a `const` would be observable holding a value it was never assigned, and the promise "a `const` binding always has the value you gave it" would be false for the top of its scope. Making early access throw preserves that guarantee, and as a bonus turns use-before-initialize — a genuine ordering bug — into a loud, precisely located error instead of a silent `undefined` travelling through the program. ## What an interviewer is listening for The three states, the two boundaries (scope entry, declaration evaluation), "per binding, not per scope", and above all the temporal-not-spatial point demonstrated with a closure that works or throws depending only on when it is called.