Hoisting and the Temporal Dead Zone

## What the snippet prints ```js console.log(a); // undefined var a = 1; console.log(b); // ReferenceError: Cannot access 'b' before initialization let b = 2; ``` The first log succeeds and prints `undefined`. The second one throws, so execution stops there and `let b = 2;` never runs. The exact wording of the error is engine-specific — V8 says "Cannot access 'b' before initialization", SpiderMonkey says "can't access lexical declaration 'b' before initialization", JavaScriptCore says "Cannot access uninitialized variable" — but every engine throws a `ReferenceError`. ## Bindings are created when the scope is entered Before a single statement of a script, function body, or block executes, the engine scans that piece of code and builds an *Environment Record*: a table mapping every name declared in the scope to a storage slot. The specification does this in abstract operations named GlobalDeclarationInstantiation, FunctionDeclarationInstantiation, and BlockDeclarationInstantiation. That setup pass is what people are pointing at when they say "hoisting". The key correction to the folklore: **nothing is moved**. The source is not rewritten and no statement is relocated to the top. The *names* simply come into existence before the lines that declare them are reached. So in the snippet above, both `a` and `b` exist as bindings of the script scope from the instant the script starts running. What differs is the state each slot is in. ## var: created and pre-initialized to undefined A `var` binding is created *and initialized to the value `undefined`* during that setup pass. That is why line 1 is legal: the slot exists and already holds a real value, so `console.log(a)` prints `undefined`. Later, when control reaches `var a = 1;`, the assignment part runs and the slot is updated to `1`. This is the source of the classic "why is my variable undefined?" bug. There is no error and no warning — just a value that is silently wrong until the assignment line executes. ```js function f() { console.log(count); // undefined, not an error var count = 3; console.log(count); // 3 } ``` ## let and const: created but left uninitialized A `let`, `const`, or `class` binding is created during the same setup pass, but is deliberately left in an *uninitialized* state — a third state distinct from "does not exist" and "holds undefined". Any read or write of the binding while it is uninitialized throws a `ReferenceError`. The window between entering the scope and evaluating the declaration is the **temporal dead zone (TDZ)**. The binding leaves the TDZ when its declaration statement is evaluated. `let b = 2;` initializes it to `2` at that point; a bare `let b;` initializes it to `undefined` at that point; `const` cannot be written without an initializer at all, so it is always initialized by its declaration. ## The assignment is never hoisted A frequent half-understanding is "the declaration and its value move to the top". Only the *binding* is set up early. This is why the following prints `undefined` rather than `1`: ```js var x = 'outer'; function g() { console.log(x); // undefined — the inner var x shadows the outer one for the whole function var x = 'inner'; } g(); ``` The inner `var x` binding exists for the entire function body, so the outer `x` is not visible inside `g` at all, and its value is `undefined` until the assignment runs. ## Why the throw is the better behaviour `var`'s pre-initialization turns a genuine ordering mistake — using a value before you have computed it — into a silent `undefined` that propagates: it flows into string concatenation as `"undefined"`, into arithmetic as `NaN`, and into a property access as a crash somewhere far from the cause. The TDZ makes the same mistake fail loudly, at the exact line and with the offending name in the message. That is the practical reason modern code uses `const` by default, `let` when reassignment is needed, and lint rules that ban `var`. ## What to say in an interview State the output first (`undefined`, then a `ReferenceError`), then give the one-sentence mechanism: every declaration in a scope gets a binding when the scope is entered; `var` bindings start out holding `undefined`, `let`/`const` bindings start out uninitialized and throw until their declaration runs. Finish by pointing out that the *assignments* never move — that detail is what separates a memorised answer from an understood one.