DEV Community: Gaurav Singh

# JavaScript Hoisting — What Actually Happens Behind the Scenes ?

Gaurav Singh — Wed, 08 Jul 2026 13:52:38 +0000

Demystifying Hoisting: What Really Happens Inside the JavaScript Engine

Most JavaScript developers have heard the common statement: "JavaScript moves variables and functions to the top of your file." While this explanation is widespread, it is technically incorrect. Hoisting is not code movement. Nothing is physically shifted around in your source file. Instead, hoisting is the direct result of how the JavaScript engine prepares memory before executing a single line of your code.

Once you understand what happens internally during this preparation step, hoisting becomes one of the easiest JavaScript concepts to grasp.

Why Hoisting Exists: The Two-Pass Model

JavaScript does not just execute your code immediately, line by line. Before execution starts, the JavaScript engine performs a crucial preparation step where it scans your code, identifies variables and functions, and allocates memory for them.

This process happens in two distinct phases:

Memory Creation Phase: The engine scans the code and allocates memory slots for all declarations. This is when hoisting happens.
Execution Phase: The engine runs your code line by line, assigning values and executing functions.

A Simple Real-Life Analogy

Imagine students entering an examination hall. Before they begin writing their papers:

Answer sheets are distributed.
Roll numbers are assigned to desks.
Seating arrangements are completed.

Only after all preparations are finished does the actual exam begin. JavaScript behaves exactly the same way. Before executing code, variables and functions are discovered, and memory space is allocated.

Defining Hoisting Accurately

The Beginner-Friendly Definition: Hoisting is JavaScript's behavior of making declarations available before execution starts.
The Technically Accurate Definition: Hoisting is the memory allocation process performed during the creation phase of an Execution Context.

Deep Dive: 4 Core Examples of Hoisting

Example 1: Variable Hoisting with `var`

console.log(a);
var a = 10;

Output:

undefined

Many beginners expect a ReferenceError here. Why does JavaScript print undefined instead?

What Happens Internally?

During the Memory Creation Phase, the engine encounters var a = 10;. It splits this into declaration and assignment, allocates memory for a, and automatically initializes it with a default value of undefined.

Variable	Initial Value
`a`	`undefined`

When the Execution Phase starts:

Step 1: console.log(a); runs. At this exact moment, a holds the value undefined.
Step 2: a = 10; runs, updating the value in memory from undefined to 10.

This is why var variables can be accessed before their formal declaration without throwing an error.

Example 2: Function Hoisting

sayHello();

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

Output:

Hello

Function declarations are treated differently from variables. During the creation phase, JavaScript stores the entire function definition in memory right away.

Name	Stored Value
`sayHello`	`function sayHello() { ... }` (Complete Function)

Because the complete function is fully hoisted and available before execution begins, you can safely invoke it at the very top of your script.

Example 3: Function Expressions

What happens when you combine a function with a variable declaration?

sayHi();

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

Output:

TypeError: sayHi is not a function

This surprises many developers. Why does it fail?

During the Memory Creation Phase, the engine treats var sayHi like any other variable. It allocates memory and initializes it to undefined. The function assignment itself is ignored until the execution phase.

Variable	Value
`sayHi`	`undefined`

During execution, the engine reaches sayHi(); and translates it to undefined();. Because undefined is not a callable function data type, JavaScript throws a TypeError. The variable container is hoisted, but the function assignment is not.

Example 4: Hoisting with `let` and `const`

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

Output:

ReferenceError: Cannot access 'a' before initialization

At first glance, it appears that let and const are not hoisted. But that is a misconception—they are hoisted.

When the engine scans code during the memory phase, it allocates space for let and const variables. However, unlike var, they are not initialized with undefined. Instead, they are placed in an uninitialized state known as the Temporal Dead Zone (TDZ).

Variable	State
`a`	Uninitialized (Temporal Dead Zone)

Attempting to read or write to a variable while it sits in the TDZ results in a ReferenceError. The variable only becomes safely usable after the execution flow reaches the line where it is formally initialized.

Quick Reference Summary

The following tables break down how different declarations are treated during the internal memory creation phase.

Declaration Behaviors

Feature	`var`	`let`	`const`
Hoisted	Yes	Yes	Yes
Initial Value	`undefined`	Uninitialized	Uninitialized
Access Before Dec.	`undefined`	`ReferenceError`	`ReferenceError`
Scope	Function	Block	Block

Memory Phase Blueprint

Type	Memory Phase State
`var`	`undefined`
`function`	Stores Entire Function
`let`	uninitialized (TDZ)
`const`	uninitialized (TDZ)

How JavaScript Executes Code: Behind the Scenes

To truly tie this all together, we have to look at the execution environment itself. When a web browser encounters a script tag, it passes the source code down to its respective engine (such as Google Chrome's V8, Mozilla Firefox's SpiderMonkey, or Safari's JavaScriptCore).

The engine processes your file using a mechanism called the Execution Context—an environment wrapper that manages the execution variables, functions, scopes, and the this evaluation.

The Call Stack

JavaScript handles execution contexts using a Call Stack. Think of it as a stack of dishes where the last item added is the first one to be cleared:

function one() {
  two();
}
function two() {
  console.log("Hello");
}
one();

Global Execution Context is created and pushed to the bottom of the stack when the script loads.
one() is invoked $\rightarrow$ Its execution context is pushed onto the stack.
two() is invoked inside one() $\rightarrow$ Its execution context is pushed to the top.
two() finishes $\rightarrow$ Popped off the stack.
one() finishes $\rightarrow$ Popped off the stack.

Complete Internal Flow Example

Let's look at a complete program to see how memory creation and execution phases pair together:

var x = 5;
function square(n) {
  return n * n;
}
var result = square(x);
console.log(result);

Phase 1: Memory Creation

Before running line one, the global memory environment maps out your declarations:

x is registered and set to undefined.
square is registered, storing its entire block logic.
result is registered and set to undefined.

Phase 2: Code Execution

Line 1: x is assigned the value 5.
Line 2: The engine skips over the function declaration since it's already stored.
Line 3: square(x) is evaluated. A new local function execution context is spawned on the Call Stack, passing 5 into the parameter n. It computes $5 \times 5$, returns 25, and destroys its local environment context. result is updated to 25.
Line 4: Outputs 25 directly to the console.

Wrapping Up: The Ultimate Mental Model

Whenever your JavaScript programs run, remember this four-step mental checklist:

Create an Execution Context.
Scan for variable and function declarations.
Allocate memory slots (initializing variables based on their keywords).
Execute the remaining source code line by line.

Hoisting isn't a magical code-lifting feature. It is simply the JavaScript engine taking a moment to set up its memory grid before letting your program loose!

# Understanding JavaScript Closures Through Call Stack, Heap Memory & `[[Scopes]]`

Gaurav Singh — Fri, 26 Jun 2026 06:27:39 +0000

Closures aren't magic—they're simply JavaScript's way of keeping data alive when a function still needs it.

Every JavaScript developer has heard statements like:

"A closure is a function that remembers variables from its outer scope."
"The inner function closes over variables."
"Closures preserve the lexical environment."

But...

How does a function actually remember variables?
Where are those variables stored after the outer function finishes?
Why doesn't JavaScript delete them?

Let's go beyond the textbook definition and see what actually happens inside the JavaScript engine.

The Two Main Players Inside the JavaScript Engine

Whenever a function executes, two important memory areas are involved:

Call Stack
Heap Memory

Understanding closures is really about understanding where JavaScript stores variables and why some of them survive after a function finishes executing.

1. What Happens in a Normal Function?

Consider a simple function:

function greet() {
    let name = "JavaScript";
    console.log(name);
}

greet();

When greet() executes:

An Execution Context is created.
Local variables (name) belong to that execution.
The execution context is pushed onto the Call Stack.

Call Stack

┌─────────────────────────┐
│ Execution Context       │
│ name = "JavaScript"     │
└─────────────────────────┘

After the function finishes:

The execution context is popped off the stack.
No code references name anymore.
It becomes eligible for Garbage Collection.

Everything is cleaned up.

2. What Changes When a Closure Is Created?

Now look at this example:

function outerFunction() {

    let count = 0;

    function innerFunction() {
        count++;
        console.log(count);
    }

    return innerFunction;
}

const counter = outerFunction();

counter();
counter();
counter();

Output

1
2
3

But wait...

outerFunction() already finished executing.

Its execution context has been removed from the Call Stack.

So why is count still available?

That's where closures come in.

Behind the Scenes

When JavaScript notices that innerFunction uses count, it understands:

"This variable will still be needed after outerFunction() returns."

Instead of letting count disappear with the execution context, the engine keeps it alive.

Three important things happen behind the scenes.

Step A — Captured Variables Are Kept in Heap Memory

The variables that are captured by an inner function are stored inside an internal object called the Lexical Environment (often called the Closure Context).

Conceptually, you can think of it like this:

Heap Memory

Lexical Environment

{
    count: 0
}

Unlike the Call Stack, heap memory isn't destroyed when the function returns.

This allows the captured variables to stay alive.

Note: Engines don't literally "move" variables from the stack to the heap. Instead, captured variables are stored in a heap-allocated lexical environment so they can outlive the function call.

Step B — The Secret Link (`[[Scopes]]`)

Every function internally carries a hidden reference called:

[[Scopes]]

This hidden reference points to the lexical environment containing the variables it needs.

Conceptually:

counter
   │
   ▼
[[Scopes]]
   │
   ▼
Lexical Environment
{
   count: 0
}

Even after outerFunction() has finished, the returned function still knows exactly where count lives.

Step C — The Scope Chain

Later, when you execute:

counter();

JavaScript performs variable lookup in this order:

Check the function's local scope.
If not found, follow [[Scopes]].
Search the lexical environment.
Continue upward until the variable is found.

This lookup process is called the Scope Chain.

Visualizing the Entire Process

Before `outerFunction()` Returns

Call Stack

┌────────────────────────────┐
│ outerFunction()            │
│ count = 0                  │
│ innerFunction()            │
└────────────────────────────┘

After Returning

Call Stack

┌──────────────────────┐
│ Global Execution     │
└──────────────────────┘


Heap Memory

┌────────────────────────┐
│ Lexical Environment    │
│ count = 0              │
└────────────────────────┘

        ▲
        │
     [[Scopes]]
        │
        ▼

innerFunction

The execution context is gone.

The variable survives because the returned function still references it.

A Simple Analogy

Imagine:

outerFunction() is a hotel room.
count is an important document.
Before checking out, you place the document in a secure locker (Heap Memory).
You hand the locker key ([[Scopes]]) to your child (innerFunction).

Even after the hotel room is empty, your child still has the key and can access the document whenever needed.

That's exactly how closures work.

Why Are Closures Useful?

1. Data Privacy

Closures let you create private variables.

function createCounter() {

    let count = 0;

    return {
        increment() {
            count++;
        },

        getCount() {
            return count;
        }
    };
}

Nobody outside can directly modify count.

2. Maintaining State

Closures allow functions to remember information between calls.

const counter = outerFunction();

counter();
counter();
counter();

The value of count persists without using global variables.

Key Takeaways

✔ A closure is created when an inner function uses variables from its outer scope.

✔ JavaScript keeps those captured variables alive inside a heap-allocated lexical environment.

✔ The returned function stores a hidden reference called [[Scopes]] to that environment.

✔ As long as the function exists, the captured variables cannot be garbage collected.

✔ Variable lookup through these linked environments is called the Scope Chain.

Final Thought

Closures aren't magic.

They're simply the JavaScript engine preserving the variables that are still needed.

Once you understand the relationship between the Call Stack, Heap Memory, Lexical Environment, and the hidden [[Scopes]] reference, closures become one of the most elegant and powerful features of JavaScript.

JavaScript Lexical Scope, Lexical Environment, Scope Chain & Closure — Explained Like the JS Engine

Gaurav Singh — Thu, 25 Jun 2026 17:23:17 +0000

Most developers memorize the definitions of Lexical Scope, Lexical Environment, Scope Chain, and Closure without understanding what actually happens inside the JavaScript engine.

In this article, we'll build these concepts step by step and understand them from the engine's perspective.

What Does "Lexical" Mean?

Lexical means:

"Based on where things are written in the source code."

JavaScript determines variable access by looking at the physical location of functions in your code—not where they are called.

1. Lexical Scope

A function can access:

Its own variables
Variables from its outer scope

The scope is determined by where a function is defined, not where it is executed.

let dynamicVar = "I'm Global";

function checkScope() {
  console.log(dynamicVar);
}

function anotherFunction() {
  let dynamicVar = "I'm Local";
  checkScope(); // Function is called here
}

anotherFunction();

Output

I'm Global

Why?

Before execution begins, JavaScript analyzes the source code and decides which variables every function can access.

This rule is called Lexical (Static) Scope.

Although checkScope() is called inside anotherFunction(), it was defined in the global scope, so it only has access to the global dynamicVar.

What If JavaScript Used Dynamic Scope?

If JavaScript used Dynamic Scope (which depends on where a function is called), the output would be:

I'm Local

But JavaScript doesn't work this way.

Lexical Scope Search Path

Before execution starts, JavaScript builds a blueprint of variable accessibility by analyzing the code structure.

Think of it as answering this question:

"Which variables can each function access?"

That blueprint is called Lexical Scope.

2. Lexical Environment

A Lexical Environment is an internal object created whenever JavaScript starts executing a scope.

It stores:

Local variables
Function declarations
A reference to its parent lexical environment

It consists of:

Environment Record → Stores variables and functions
Outer Reference → Points to the parent lexical environment

Together, these make variable lookup possible.

Scope Chain

The Scope Chain is formed by connecting lexical environments through their Outer References.

When JavaScript can't find a variable in the current scope, it walks up this chain until it either finds the variable or reaches the global scope.

Easy Way to Remember

Lexical Scope is the rule that defines what a function can access.

Lexical Environment is the place where those variables are actually stored.

Interview Definition

Lexical Scope defines what a function can access, while the Lexical Environment stores those variables and maintains the relationship between parent and child scopes.

Example

const globalVar = "I am Global";

function outerFunction() {
  const outerVar = "I am Outer";

  function innerFunction() {
    const innerVar = "I am Local";

    console.log(innerVar);
    console.log(outerVar);
    console.log(globalVar);
  }

  innerFunction();
}

outerFunction();

Output

I am Local
I am Outer
I am Global

What Happens Behind the Scenes?

When innerFunction() starts executing:

JavaScript creates a brand new Lexical Environment.

It contains:

Lexical Environment (innerFunction)

Environment Record
------------------
innerVar

Outer Reference
      ↓
Lexical Environment (outerFunction)

Environment Record
------------------
outerVar

Outer Reference
      ↓
Global Lexical Environment

Environment Record
------------------
globalVar

Now suppose JavaScript needs outerVar.

The lookup process becomes:

Current Scope
      ↓
Parent Scope
      ↓
Global Scope

This lookup path is called the Scope Chain.

3. Closure

A Closure is formed when a function remembers and retains access to its outer lexical environment even after the outer function has finished execution.

In My Style

When we return an inner function, pass it as a callback, or store it in a variable, and it carries its lexical environment along with it, that is called a Closure.

Example

function outerFunction() {
  let a = 10;

  function innerFunction() {
    a++;
    console.log(a);
  }

  return innerFunction;
}

const fn = outerFunction();

fn();
fn();
fn();

Output

11
12
13

Why Doesn't `a` Disappear?

Normally, when outerFunction() finishes execution, its execution context is removed from the call stack.

But JavaScript notices that innerFunction still needs a.

Instead of destroying that memory, JavaScript keeps the lexical environment alive.

The returned function holds a hidden reference to it.

This preserved relationship is called a Closure.

One Snap > 100 Closure Definitions 📸

Someone asks:

"Where is the closure?"

Open Chrome DevTools:

console.dir(fn)

Expand:

[[Scopes]]

Closure (outerFunction)
{
    a: 13
}

There it is.

That hidden Closure object is the preserved lexical environment that keeps your variables alive even after the outer function has returned.

Final One-Line Difference

Concept	Meaning
Lexical Scope	Defines what a function can access.
Lexical Environment	Stores variables and references to parent scopes.
Scope Chain	The path JavaScript follows to find variables.
Closure	A function together with the preserved lexical environment it remembers after the outer function has finished execution.

Key Takeaways

⟶ Lexical means where code is written.
⟶ Scope is determined during parsing, not during function calls.
⟶ Every executing scope gets its own Lexical Environment.
⟶ Lexical Environments are connected through Outer References.
⟶ Those references create the Scope Chain.
⟶ A Closure keeps a lexical environment alive as long as a function still references it.

If this article helped you understand what's happening inside the JavaScript engine, consider leaving a ❤️ and sharing it with fellow developers.

Happy Coding!

DEV Community: Gaurav Singh

# JavaScript Hoisting — What Actually Happens Behind the Scenes ?

Demystifying Hoisting: What Really Happens Inside the JavaScript Engine

Why Hoisting Exists: The Two-Pass Model

A Simple Real-Life Analogy

Defining Hoisting Accurately

Deep Dive: 4 Core Examples of Hoisting

Example 1: Variable Hoisting with var

What Happens Internally?

Example 2: Function Hoisting

Example 3: Function Expressions

Example 4: Hoisting with let and const

Quick Reference Summary

Declaration Behaviors

Memory Phase Blueprint

How JavaScript Executes Code: Behind the Scenes

The Call Stack

Complete Internal Flow Example

Phase 1: Memory Creation

Phase 2: Code Execution

Wrapping Up: The Ultimate Mental Model

# Understanding JavaScript Closures Through Call Stack, Heap Memory & `[[Scopes]]`

The Two Main Players Inside the JavaScript Engine

1. What Happens in a Normal Function?

2. What Changes When a Closure Is Created?

Behind the Scenes

Step A — Captured Variables Are Kept in Heap Memory

Step B — The Secret Link ([[Scopes]])

Step C — The Scope Chain

Visualizing the Entire Process

Before outerFunction() Returns

After Returning

A Simple Analogy

Why Are Closures Useful?

1. Data Privacy

2. Maintaining State

Key Takeaways

Final Thought

JavaScript Lexical Scope, Lexical Environment, Scope Chain & Closure — Explained Like the JS Engine

1. Lexical Scope

Output

Why?

What If JavaScript Used Dynamic Scope?

Lexical Scope Search Path

2. Lexical Environment

Scope Chain

Easy Way to Remember

Interview Definition

Example

Output

What Happens Behind the Scenes?

3. Closure

In My Style

Example

Output

Why Doesn't a Disappear?

One Snap > 100 Closure Definitions 📸

Key Takeaways

Example 1: Variable Hoisting with `var`

Example 4: Hoisting with `let` and `const`

Step B — The Secret Link (`[[Scopes]]`)

Before `outerFunction()` Returns

Why Doesn't `a` Disappear?