🪄 JavaScript Hoisting: The Secrets Behind the Code

(Where does your code go before it even runs, who does it take along, and why does it sometimes embarrass you?)

There are some things in JavaScript…
You think you wrote them down below,
but JavaScript has already moved them up.

Hoisting is one of JavaScript’s most dramatic, most misunderstood, and most bug-producing mechanisms behind the scenes.
In this article, we’ll cover:

What hoisting really is
How JavaScript reads and executes code
Why var, let, and const behave differently
Why functions shout “I’m already here!”
And why we mess things up in real life

All explained with humor, examples, and practical tips.

If you’re ready, let’s pull back the curtain 🎭

🧠 What Does JavaScript Do Before Running Your Code?

JavaScript doesn’t execute your code line by line immediately.
First, it says:

“Hold on… let me see who’s a variable, who’s a function, and who’s about to cause drama.”

This process happens in two phases:

1️⃣ Creation Phase

Variable names are stored in memory
Function declarations are stored in memory
var → undefined
let / const → TDZ (we’ll get there)

2️⃣ Execution Phase

Code runs line by line
Values are assigned
Functions are called

📌 Hoisting happens during the Creation Phase.

🎈 What Is Hoisting? (Clear and Simple)

Hoisting is JavaScript moving variable and function declarations into memory before the code executes.

⚠️ But here’s the critical part:

❗ Only declarations are hoisted, not assignments.

Memorize this sentence.
Put it on your wall.
Write it on your coffee mug.

🧪 Hoisting with `var`: Old but Dangerous

console.log(username);
var username = "Cansu";

Output:

undefined

“Shouldn’t this throw an error?”

Here’s how JavaScript actually sees it:

var username; // hoisted
console.log(username);
username = "Cansu";

📌 var:

Is hoisted
Starts as undefined
Quietly lets bugs slip through 😈

That’s why var is:

A debugging nightmare
The curse of legacy projects
A junior developer’s rite of passage

🚪 `let` and `const`: Modern, Polite, but Strict

console.log(age);
let age = 25;

Output:

ReferenceError: Cannot access 'age' before initialization

“Wait… aren’t they hoisted?”

They are.
But…

🕳️ Temporal Dead Zone (TDZ)

For let and const, JavaScript basically says:

“I know you exist…
But you’re not allowed to speak yet.”

TDZ means:

The variable is known
But cannot be accessed

{
  // TDZ starts here
  console.log(x); // ❌
  let x = 10;
}

📌 This behavior is intentional:

It catches errors early
It enforces better coding discipline

🧙 Function Hoisting: The Real Show Starts Here

🟢 Function Declaration (The Reliable Hero)

sayHello();

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

✔️ Works perfectly.

Because:

The entire function is hoisted
Both its name and body exist in memory

🔴 Function Expression: The Masked Character

sayHi();

var sayHi = function () {
  console.log("Hi!");
};

❌ Doesn’t work.

Why?

var sayHi; // undefined
sayHi();   // ❌ undefined is not a function

📌 Because:

The variable is hoisted
The function assignment is not

🏹 Arrow Functions + Hoisting = A Trap

hello();

const hello = () => {
  console.log("Hello JS!");
};

❌ ReferenceError

Arrow functions:

Are defined with const / let
Live inside the TDZ
Can’t speak before their turn

😵 Real-Life Hoisting Mistakes

❌ Unexpected `undefined`

if (!user) {
  var user = "guest";
}

console.log(user);

Result:

guest

Even though it was inside the if 😶

Reason:

var is not block-scoped

🧠 Practical Rules (Worth Gold)

✨ Define variables before using them
✨ Don’t use var (yes, really)
✨ Place functions at the top of your file
✨ Make const your default choice
✨ Know hoisting — but don’t rely on it

🎓 Mini Quiz (Test Yourself)

console.log(a);
let a = 5;

A) undefined
B) 5
C) ReferenceError

👉 Correct answer: C

❤️ Final Words

Hoisting is a secret JavaScript whispers to you:

“Your code is prepared earlier than you think.”

But when you’re aware of it:

Hoisting won’t hurt you
Your code becomes cleaner
Bugs decrease

And JavaScript throws fewer tantrums at you 😌