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

Tue, 07 Jul 2026 17:34:11 +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.

Coder Legion - Recent posts tagged heapmemory