Why JavaScript Feels Out of Order: Understanding Hoisting

There’s a moment when learning JavaScript where something just doesn’t feel right.

You write code from top to bottom…

but JavaScript behaves as if it read something earlier than it should.

A variable exists before it’s declared.

A function works before it’s defined.

And you start wondering:

Is JavaScript ignoring the order of my code?

Not exactly.

It’s following a different process.

JavaScript Doesn’t Execute Immediately

When JavaScript runs your code, it doesn’t just execute line by line.

Before anything runs, it goes through a setup step.

A preparation phase.

In this phase, it scans your code and registers:

• variables
• functions
• scope

Only after that does execution begin.

This is what creates the behavior we call hoisting.

Hoisting Is Not Moving Code

A common explanation says:

“JavaScript moves declarations to the top.”

That’s not really what happens.

Nothing is physically moved.

Instead, JavaScript builds a mental map of your code before running it.

It allocates memory.

It prepares references.

And that preparation changes how your code behaves.

Why var Becomes undefined

Consider this:

console.log(a)
var a = 10

At first glance, it feels like this should fail.

But during the setup phase, JavaScript registers a and gives it a default value:

var a = undefined

So when execution starts:

console.log(a) // undefined
a = 10

This behavior comes from early JavaScript design.

The language prioritized flexibility.

Instead of throwing errors, it allowed variables to exist early…

even if they weren’t fully initialized.

Why let and const Throw Errors

Now compare that with:

console.log(a)
let a = 10

This time, you get a ReferenceError.

Why?

Because modern JavaScript introduced a stricter rule.

Variables declared with let and const are still registered during setup…

but they are not initialized.

They exist in a state called the Temporal Dead Zone.

From the start of the scope until the declaration line, the variable is:

• known to JavaScript
• but not accessible

This was a deliberate design decision.

It prevents accidental usage before a variable is ready.

In other words, it trades flexibility for safety.

Why Function Declarations Just Work

Now consider this:

sayHello()

function sayHello() {
  console.log("Hello")
}

This works perfectly.

Because during the setup phase, function declarations are fully stored in memory.

Not just their name…

but their entire implementation.

So when execution begins, the function is already available.

This behavior exists because functions often need to be called before their definition, especially in older JavaScript patterns.

Why Function Expressions Fail

Now look at this:

sayHello()

var sayHello = function () {
  console.log("Hello")
}

This fails with a TypeError.

Even though it looks similar.

The reason is subtle but important.

This is not a function declaration.

It’s a variable assignment.

During setup, JavaScript treats it like this:

var sayHello = undefined

So when execution starts:

sayHello() // undefined is not a function

Only later does the function get assigned.

The difference is not about syntax.

It’s about how JavaScript categorizes the declaration.

The Pattern Behind Everything

If you step back, all of these behaviors follow one rule.

JavaScript prepares memory differently depending on what you declare.

• var → created and initialized as undefined
• let/const → created but not initialized (TDZ)
• function declaration → fully initialized
• function expression → treated as a variable

Each keyword is a signal.

It tells JavaScript how to prepare that piece of code before execution.

The Real System Behind Hoisting

Underneath all of this is something deeper.

Execution context.

When JavaScript runs your code, it creates an environment where:

• variables are stored
• functions are stored
• scope is defined

This environment is built before execution.

And hoisting is simply the visible effect of that process.

Why This Design Exists

Early JavaScript was designed to be forgiving.

It allowed flexibility, even if it meant some confusion.

Later versions introduced stricter rules like let and const to reduce bugs.

So what you’re seeing is not inconsistency.

It’s evolution.

A language balancing:

• flexibility
• safety
• backward compatibility

A Better Way to Think About It

Instead of thinking:

“Why is JavaScript ignoring order?”

Think:

“How did JavaScript prepare this before running it?”

That shift makes everything clearer.

Because the behavior is not random.

It’s the result of a system working exactly as designed.

A Final Thought

Hoisting isn’t a trick.

It’s a glimpse into how JavaScript actually works.

It reveals that your code isn’t just executed…

it’s first understood.

And once you see that…

the confusion fades.

Because now you’re not just reading code…

you’re thinking like the engine.