⏱️ Reading time: 6-8 minutes
🎯 Difficulty: Intermediate
📂 Themes: Memory Management, JavaScript Internals, Angular, Performance

What's inside?

• 🔍 The Problem: My journey toward becoming a senior developer — and the question that started it all.
• 📦 Stack & Heap: Where data actually lives in RAM — and why it matters.
• 🔗 Value vs Reference Types: Why copying objects is more dangerous than you think.
• 🔒 const and Object.freeze: What they actually protect — and what they don't.
• 🧹 Garbage Collection: Where memory leaks really come from.
• ⚡ Change Detection: How Angular uses everything above to decide when to re-render.

🔍 The Problem

I've been working as a frontend developer for quite some time.
Self-taught, no CS degree — just building real Angular
applications in production.

At some point I made a decision: I want to become a senior
developer. Not just someone who makes things work, but someone
who understands why they work.

So I started going deep. My first target was Angular Change
Detection — I knew Angular compared values to decide when to
re-render. But when I looked closer, a simple question stopped me:

Why does this return false?

[] === [] // false

And why does this return true?

"10" === "10" // true

I knew the answers from experience. But I couldn't explain them
at a fundamental level — and that gap bothered me.

That question pulled me deeper. Change Detection led me to
references. References led me to memory. And memory led me to
two concepts I should have learned a long time ago:
Stack and Heap.

This is the first post in my Road to Senior series —
documenting everything I'm learning on the way to becoming
a senior developer. Starting where I probably should have
started from the beginning.

📦 Stack & Heap — Where Your Data Actually Lives

Most JavaScript developers know variables store data.
But very few know where that data physically lives in memory.

The answer is: it depends on what type of data it is.

Your computer's RAM is divided into two distinct regions:
the Stack and the Heap. They exist for different
purposes, behave differently, and understanding the difference
will change how you think about JavaScript forever.

The Stack

Think of the Stack like a pile of trays in a cafeteria.
You add trays to the top, you take trays from the top.
Last in, first out — always.

The Stack is:

• Fast — adding and removing data is just moving a pointer
• Small — typically 1-8 MB
• Automatic — data is cleaned up the moment a function ends
• Fixed-size — every slot must have a known, predictable size

When you call a function, JavaScript creates a new "frame"
on the Stack for that function's local variables.
When the function returns, the frame is gone.

function greet() {
  let name = "Jan"  // stored directly on the Stack
  let age = 25      // stored directly on the Stack
}
// function ends → both variables are gone from Stack

This works perfectly for numbers, booleans, and strings —
types with a fixed, predictable size.

The Heap

The Heap is different. Think of it as a large,
unorganized warehouse. When you need space for something,
the system finds a free spot, stores it there,
and gives you the address of where it put it.

The Heap is:

• Large — can grow to gigabytes
• Flexible — can store data of unknown or dynamic size
• Managed — cleaned up by the Garbage Collector (more on this later)
• Slower — finding free space takes more work than moving a pointer

Objects live here. Because an object can have 2 properties
or 200 — JavaScript doesn't know the size in advance.

const user = { name: "Jan", role: "admin" }
//  ↑ address stored on Stack
//                ↑ actual object stored on Heap

The Key Insight

When you create an object, two things happen:

1. The actual object is created somewhere in the Heap
2. A reference (memory address) to that object is stored on the Stack

const user = { name: "Jan" }

// Stack              Heap
// ─────────────      ─────────────────────
// user → 0x4A2F  →  { name: "Jan" }
// ─────────────      ─────────────────────

The variable user doesn't hold the object.
It holds the address of where the object lives.

This is why they're called reference types —
and it's exactly what makes copying objects so dangerous.
Which brings us to the next topic.

🔗 Value vs Reference Types

Now that you know about Stack and Heap, this next part
will make complete sense.

JavaScript has two categories of data types — and they
behave completely differently when you copy them.

Value Types

These seven types store their value directly on the Stack:

• number — 42, 3.14, -7
• string — "hello", 'Jan'
• boolean — true, false
• null
• undefined
• symbol
• bigint

When you copy a value type, JavaScript copies the actual value.
The two variables are completely independent.

let a = 42
let b = a   // copies the VALUE — b gets its own slot on the Stack
b = 99

console.log(a) // 42 — untouched
console.log(b) // 99

Changing b has zero effect on a. They live in separate
memory slots on the Stack.

Reference Types

Everything else is a reference type:

• object — {}, { name: 'Jan' }
• array — [], [1, 2, 3]
• function — () => {}
• Map, Set
• class instances — new User()

When you copy a reference type, JavaScript copies the address —
not the object itself. Both variables point to the
same object in the Heap.

const a = { name: 'Jan' }
const b = a   // copies the ADDRESS — both point to the same object

b.name = 'Eva'

console.log(a.name) // 'Eva' — original changed!
console.log(b.name) // 'Eva'

There is only one object in the Heap. Two variables, one address.
Changing it through b changes it for a as well —
because they're the same thing.

The Fix — Create a New Reference

If you want a truly independent copy, you need to create
a new object in the Heap with its own address.
The spread operator does exactly that:

const a = { name: 'Jan' }
const updated = { ...a, name: 'Eva' } // new object in Heap

console.log(a.name)       // 'Jan' — untouched
console.log(updated.name) // 'Eva'

Two different addresses. Two independent objects.

How === Actually Works

This is where most developers get surprised.

For value types, === compares the actual values:

"10" === "10" // true — same value
42  === 42    // true — same value

For reference types, === compares the addresses —
not the contents:

[] === []  // false — two different addresses in Heap
{} === {}  // false — two different addresses in Heap

Even though the contents look identical, each [] and {}
creates a brand new object at a new address in the Heap.
Different addresses → false.

But this returns true:

const a = { name: 'Jan' }
const b = a

a === b // true — same address

The rule: === on reference types is not asking
"do these objects look the same?"
It's asking "are these the exact same object in memory?"

Now you understand references. But what does const actually
protect — and what doesn't it protect? That's next.

🔒 const and Object.freeze

By now you know that variables store either a value
(on the Stack) or an address (on the Stack, pointing to the Heap).

const and Object.freeze both sound like they "lock" things.
But they lock very different things — and confusing them
is one of the most common mistakes in JavaScript.

What const Actually Does

const locks the Stack slot. That's it.

It prevents you from reassigning the variable —
meaning you can't make it point to a different address.

const user = { name: 'Jan' }

user = { name: 'Eva' } // ❌ TypeError — trying to change the Stack slot

But the object in the Heap? Completely unprotected.

const user = { name: 'Jan' }

user.name = 'Eva' // ✅ works — we're changing the Heap, not the Stack slot

Stack              Heap
─────────────      ─────────────────────
user → 0x4A2F 🔒  { name: 'Eva' }  ← unprotected, freely mutable
─────────────

const does not mean immutable. It means
the reference cannot be reassigned.

What Object.freeze Does

Object.freeze locks the Heap content.
It prevents adding, removing, or changing properties on the object.

const user = Object.freeze({ name: 'Jan' })

user.name = 'Eva'  // ❌ silently fails (or TypeError in strict mode)
user.age = 30      // ❌ silently fails

Now the Heap content is protected.

Stack              Heap
─────────────      ─────────────────────
user → 0x4A2F 🔒  { name: 'Jan' } 🔒
─────────────

Both the Stack slot and the Heap content are locked.
This is the closest JavaScript gets to a truly immutable object.

The Catch — freeze is Shallow

Object.freeze only protects the first level.
Nested objects are still mutable.

const user = Object.freeze({
  name: 'Jan',
  address: { city: 'Prague' }  // nested object — NOT frozen
})

user.name = 'Eva'          // ❌ blocked
user.address.city = 'Brno' // ✅ works — nested object is unprotected

To freeze deeply, you'd need to recursively freeze
every nested object — known as a "deep freeze."
JavaScript doesn't have this built in.

Quick Summary

If const meant truly immutable,
Object.freeze wouldn't need to exist.

Now you understand how references work and how to protect them.
But what happens to objects when nothing references them anymore?
That's where memory leaks come from.

🧹 Garbage Collection — Where Memory Leaks Really Come From

In C or C++, when you allocate memory, you are responsible
for freeing it. Forget to free it — memory leak.
Free it twice — crash.

JavaScript handles this automatically. That's the job of
the Garbage Collector (GC).

But "automatic" doesn't mean "bulletproof."
Understanding how GC works is exactly what separates
developers who write memory-safe code from those who don't.

The Fundamental Rule

As long as a reference to an object exists,
the GC will not delete it.

An object without any reference pointing to it is considered
"dead" — unreachable. The GC is free to delete it and
reclaim that memory.

This one rule explains every memory leak you'll ever encounter.

How It Works — Mark-and-Sweep

The algorithm V8 uses is called mark-and-sweep.
It runs in two phases:

Phase 1 — Mark

The GC starts from the "roots" — the Stack, global variables,
and currently executing functions. It follows every reference
and marks every reachable object.

Phase 2 — Sweep

Everything that wasn't marked is considered unreachable.
The GC deletes it and frees the memory.

Stack (roots)          Heap
──────────────         ──────────────────────────
user → 0x01    →  ✅  { name: 'Jan', addr: 0x02 }
                  ✅  { city: 'Prague' }  ← reachable via 0x01
                  ❌  { name: 'old' }     ← nothing points here → deleted
──────────────

Notice: the object at 0x02 is kept even though the Stack
doesn't point to it directly — it's reachable through 0x01.
The GC follows the entire chain of references.

When Does GC Run?

You can't control it. You can't call it manually.
V8 decides when to run it based on memory pressure.

V8 uses two types of GC:

• Minor GC — fast, runs frequently, cleans up short-lived objects
• Major GC — slow, runs rarely, cleans the entire Heap. Can briefly pause the JS thread — which is why avoiding unnecessary object creation matters in performance-critical code.

Memory Leaks — When GC Can't Help You

A memory leak happens when you hold a reference to an object
you no longer need. The GC sees the reference and thinks
you still need it. It can't delete it.

The most common source of memory leaks in Angular?
Forgotten subscriptions.

// ❌ leak — subscription stays alive after component is destroyed
ngOnInit() {
  this.service.data$.subscribe(d => {
    this.data = d
  })
}
// component gets destroyed
// but the subscription still holds a reference to this component
// GC cannot clean it up

Every time a user navigates to this component and away,
another subscription is created. None of them are cleaned up.
The app slowly gets slower.

The fix:

// ✅ option 1 — manual unsubscribe
ngOnDestroy() {
  this.subscription.unsubscribe()
}

// ✅ option 2 — modern Angular
data = toSignal(this.service.data$) // auto-unsubscribes on destroy

// ✅ option 3 — also modern Angular
this.service.data$
  .pipe(takeUntilDestroyed())
  .subscribe(d => this.data = d)

Why Angular Cares So Much About This

Angular applications are SPAs — the page never fully reloads.
Components are created and destroyed dynamically as users navigate.

In a traditional website, navigating away reloads the page
and clears everything from memory. In an SPA, nothing clears
unless you explicitly clean it up.

A forgotten subscription creates a reference chain:

subscription → Observable → data → component

The GC sees references at every step.
Nothing gets cleaned. Memory grows. App slows down.

This is why toSignal(), takeUntilDestroyed(), and DestroyRef
exist — they're Angular's built-in answer to this problem.
They remove the reference automatically when the component is destroyed,
giving the GC what it needs to do its job.

Now you understand Stack, Heap, references, and GC.
It's time to see how Angular uses all of this to decide
when to update your UI.

⚡ Change Detection — How Angular Uses Everything Above

This is why all of the above matters.

Everything you've learned so far — Stack, Heap, references,
=== comparison — Angular's Change Detection is built
on exactly these concepts.

The Core Question

Angular's job is to keep the UI in sync with your data.
But re-rendering every component on every possible change
would be incredibly expensive.

So Angular asks a simpler question:

Did the reference change?

oldRef === newRef // true  → same address → skip
oldRef === newRef // false → new address  → re-render

That's it. Angular does a === comparison on references.
The same === you now understand at a memory level.

Why Mutation Doesn't Work

When you mutate an object, the address on the Stack
stays the same. Angular does ===, gets true,
and skips the component.

// ❌ Angular won't detect this change
this.user.name = 'Eva'

// The Stack still holds the same address → === is true → no re-render

When you create a new object with spread,
a new address is created in the Heap.
Angular does ===, gets false, and re-renders.

// ✅ Angular detects this change
this.user = { ...this.user, name: 'Eva' }

// New object in Heap → new address on Stack → === is false → re-render

This is not Angular magic. This is just === on memory addresses.

What I Know Now

When I started this journey, I had a simple question:
why does [] === [] return false?

The answer turned out to be a complete mental model:

• [] creates a new object in the Heap
• The variable stores the address on the Stack
• === compares addresses, not content
• Angular uses === to detect changes
• Mutating an object keeps the same address → no re-render
• Creating a new object creates a new address → re-render
• Keeping unnecessary references prevents GC from cleaning up → memory leak

This is the foundation. NgRx immutability, OnPush, Signals —
all of it builds on top of what you just learned.
But that's a story for another post.