Scope, hoisting and the TDZ: why your variable exists or fails on each line

Learn lexical scope, hoisting and the temporal dead zone so you can avoid ReferenceError, fix variable shadowing and write more predictable functions.

How much do you know about JavaScript?

📘 Theory

A conceptual map of scope, hoisting and the TDZ

Three connected ideas explain why a variable works in one place and breaks in another.

Scope defines where you can access a variable. Hoisting explains which declarations are processed before line-by-line execution begins. The temporal dead zone marks the stretch where `let` and `const` already exist but still cannot be used.

If you understand this trio, your errors stop feeling random and become fully traceable.

Global scope

Visible from the whole file or module.

Useful for shared configuration
Dangerous when overused because it couples too much code

Function scope

Variables live only inside the function.

Encapsulates logic
Reduces side effects

Block scope

With `let` and `const`, the variable lives inside `{}`.

`if`, `for` and `while` create blocks
It prevents accidental variable leaks

TDZ

The temporal dead zone of `let` and `const`.

The binding exists before initialization
Reading it too early causes `ReferenceError`

Lexical scope: the block decides

The place where you declare a variable determines who can see it.

JavaScript uses lexical scope. It does not matter where a function is called from. What matters is where it was defined.

In real code, that idea becomes crucial when you work with event handlers and nested functions.

Real hoisting without myths

Not everything is hoisted in the same way. One thing gets declared, another gets initialized.

Function declarations are available before their line appears. With `var`, the declaration is hoisted but the initial value is `undefined` until assignment. With `let` and `const`, there is hoisting too, but no access before initialization because of the TDZ.

That is why it helps to declare variables near the top of their block and helper functions before their first use when possible.

The TDZ: a useful error, not your enemy

The temporal dead zone protects you from using variables too early.

The TDZ begins when the block starts and ends on the line where you initialize the `let` or `const` binding.

That early `ReferenceError` prevents silent bugs that used to slip through much more easily with `var`.

If you hit the TDZ, inspect the declaration and initialization order.
Do not mix definition and use inside long blocks without structure.
Prefer smaller functions to reduce mental context.

Shadowing and naming: avoid accidental confusion

You can redeclare inside an inner block, but do it carefully.

Shadowing happens when an inner variable hides another one from an outer scope by using the same name. It is not always wrong, but it often creates confusion.

In team code, semantically different names such as `basePrice` and `priceWithTax` are usually much clearer than reusing `price` everywhere.

1 A conceptual map of scope, hoisting and the TDZ 2 Lexical scope: the block decides 3 Real hoisting without myths 4 The TDZ: a useful error, not your enemy 5 Shadowing and naming: avoid accidental confusion

🧭 Key visuals

Scope and variable visibility

It reinforces how variables are resolved depending on the execution context.

Diagram of global scope, block scope and function scope

🧪 Learn by doing

Example Guided example: scope in an access validation Observe which variables live inside the block and which ones stay accessible outside it.

⌄

Example Guided example: hoisting in a function versus `var` Compare the behavior and see why not everything gets hoisted in the same way.

⌄

Example Interactive demo: scope and TDZ viewer Choose a case and inspect the result of each scope pattern in both the preview and the console.

⌄

🏁 Challenges

Challenge Challenge 1: fix a TDZ error by changing the declaration order Reorder the code so a `let` binding is initialized before it gets used.

⌄

Challenge Challenge 2: avoid confusing shadowing Refactor the names so the inner and outer variables do not collide semantically.

⌄

🧰 Resources

Useful links

javascript.info: Variable scope and closure MDN: Scope glossary MDN: Hoisting glossary MDN: let MDN: const MDN: var

Test

Check your knowledge with a test about JavaScript.

Test for JavaScript

Course resources 62

📘 Glossary 🎧 Audio 📄 PDFs 🖼️ Infographics 🎬 Videos 🔗 Links 🧠 Flashcards 🧩 Snippets

‹

Lesson 10

Functions in JavaScript: encapsulate logic with intention

Lesson 12

Debugging in JavaScript: find the exact bug before touching the code

›