Hoisting in let and const : Understanding the Temporal Dead Zone

When I moved from var to let & const, I honestly thought I had finally understood JavaScript. Until this happened :

Boom. Reference error.

My first reaction was confusion. How did this just happen?

At that moment, Temporal Dead Zone felt like magic - something I was supposed to accept, not understand.
But once again, the answer wasn't in memorizing rules. It was hidden in the same place where hoisting, scope, and closure made sense earlier.

Execution Context.

let and const are Hoisted

One of the biggest misconceptions is:

“let and const are not hoisted.”
That’s not true.

If they were not hoisted, JavaScript would behave like this:

The error we would have gotten here:

But instead, we get here:

The error message itself is a hint.
JavaScript knows that "x" exists. It just refuses to let us touch it.
So, the real question become:

Why does JavaScript block access if the variable already exists?

What actually happens before code runs?

Before even a single line of code executes, JavaScript prepares everything behind the scenes.
It decides:

• What variables exist.
• Where they belong.
• how memory should be set up. Now here is the difference in var and let. Before the code execution, y is assigned a value "undefined" in memory. So when it runs it does not crash. That's why we can access y even before declaring it. But, for x, if I do the same as above, then it throws a reference error. Because behind the scene:

x -> uninitialised

This is not undefined.
In the case of var, it is in the global scope but in case of let and const it is in script scope.

Even before a single line code execution, let and const are allocated memory but they are stored in a different memory space than global. They are not on the global object.

This memory space can't be accessed before putting some value in them. This is called Hoisting for let & const. And that's where Temporal Dead Zone begins.

Temporal Dead Zone(TDZ) :

Temporal dead zone is the time since when this let variable is hoisted and until it is initialized with some value. The time between that is called Temporal Dead Zone.

So, the phase from hoisting until it is assigned some value is known as Temporal Dead Zone. So, whenever I try to access x variable in the temporal dead zone, it gives reference error.
Example:

From the start of the scope until

count lives in Temporal dead zone. It exists, but accessing it is not allowed.
The moment this line executes:

The Temporal Dead zone ends. From there on, everything works finally.
This works perfectly.

Why accessing before initializing falis

This is the part that clicked me.
JavaScript does not fail because it's confused. It fails on purpose. If JavaScript allows this:

Then let could quickly behave like var. That would bring back:

• accidental bugs
• unpredictable behavior
• hard-to-trace issues in large codebases So instead of returning undefined, JavaScript throws an error early and loudly. It’s saying:

“You’re using something before you’ve clearly defined it.”

And that’s a good thing.

Why TDZ exists at all

TDZ exists to enforce discipline in code order.
Consider this:

Logically, this makes no sense.
TDZ ensures:

• code reads top-to-bottom the way humans expect
• dependencies are declared before usage
• mistakes don’t silently pass

TDZ is not a limitation. It’s a guardrail.

const and TDZ

const behaves the same as let in terms of TDZ, but with one extra rule.

This fails:

Why?
Because const demands initialization at declaration.
TDZ ensures:

• constants are never half-defined
• immutability is respected from the first moment

This one line removed all confusion:

Hoisting decides existence.
Initialization decides accessibility.

• var → exists + initialized → usable
• let / const → exists + uninitialized → TDZ

Once I saw it this way, Temporal Dead Zone stopped being magical. It became inevitable.
If Execution Context was the foundation, Temporal Dead Zone is the proof that JavaScript actually cares about correctness.

If you liked this post, I’d love to hear your thoughts. Share your feedback in the comments and connect with me onLinkedIn.