DEV Community: Daniel Ledvina

Road to Senior: Where Your Data Lives

Daniel Ledvina — Mon, 11 May 2026 21:03:18 +0000

⏱️ 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:

The actual object is created somewhere in the Heap
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

	Protects Stack slot	Protects Heap content
`const`	✅	❌
`Object.freeze`	❌	✅ (shallow only)
`const` + `Object.freeze`	✅	✅ (shallow only)

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.

Closures made simple

Daniel Ledvina — Fri, 01 May 2026 14:13:25 +0000

⏱️ Reading time: 5 minutes
🎯 Difficulty: Intermediate
📂 Themes: Lexical Scope, Encapsulation, SDK Patterns, Memory Management

What's inside?

The Definition: Demystifying "Lexical Environment" and the Backpack analogy.
What are they for: How closures provide Encapsulation and State Persistence.
The Comparison: A side-by-side look at the "Global Mess" vs. the "Closure Approach."
Production Use Case: Building Secure API Clients to protect sensitive tokens.
Memory leaks: How to prevent Memory Leaks from timers and listeners.
Trade-offs: Understanding memory overhead and debugging complexity.

Closures can be intimidating at first, but if you deep dive into the concept and its connections, it all makes sense right away. Let's get a grasp of what closures are, why they are essential, and how to manage them like a pro.

The Definition

According to MDN:

"A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives a function access to its outer scope."
— MDN Web Docs

That sounds a bit academic, right? Let's clarify that "Lexical" part. In programming, "Lexical" simply means "where it is written in the code." So, a closure is just a function that remembers the physical place where it was born.

If I had to define it in short, I would say:

"An intelligent function with private memory."

Imagine a function that gets "born" inside another function. When the inner function leaves its "parent's house," it packs a backpack full of all the variables it had access to at that moment. Even after the parent function has finished its execution, the inner function carries that backpack wherever it goes.

What are they for?

The primary purpose of a closure is Encapsulation. It allows you to create private variables that cannot be accessed or modified from the outside world. It also enables State Persistence, meaning a function can "remember" data between executions without relying on messy global variables.

In essence, closures allow you to bundle "data" and "logic" together in a tiny, self-contained package.

💡 The React Connection: If you've ever used React Hooks (like useState), you are using closures! React uses a closure to "remember" your state value between re-renders. Even though your component function finishes running completely, the state stays alive in a "backpack" managed by React.

See it in action

To truly appreciate closures, look at how we manage state without them.

❌ Before: The "Global Mess" approach

If you want a counter to remember its value, you might use a global variable. But anyone else's code can accidentally overwrite it.

let count = 0; // Publicly accessible - DANGEROUS

function increment() {
  count++;
  console.log('Current count:', count);
}

increment(); // 1
count = 'Oops, I broke it'; // Someone else's code ruins your logic
increment(); // NaN

Why this approach is problematic:

🚨 Vulnerability: Because the count variable is public, any other part of your application can accidentally or intentionally overwrite it.
🏚️ Fragility: Your logic is brittle. A single line of "rogue" code—such as assigning a string to a variable expected to be a number—permanently breaks the functionality.
☁️ Pollution: As applications grow, global variables lead to "Global Scope Pollution," making it nearly impossible to track which piece of code is responsible for changing a specific value.

✅ After: The "Closure" approach

With a closure, the count variable is "closed" inside the scope. It is safe from outside interference.

function createCounter() {
  let count = 0; // Private memory - SAFE

  return function () {
    count++;
    console.log('Current count:', count);
  };
}

const myCounter = createCounter();
myCounter(); // 1
myCounter(); // 2
// 'count' cannot be accessed or ruined from here!

Why this approach wins:

🔒 Private Memory: The count variable lives only inside the createCounter scope. Once the function is executed, the variable "disappears" from the global perspective.
🔑 Exclusive Access: The only way to interact with the data is through the returned function. This function "remembers" its birthplace and carries that memory in its "backpack" wherever it goes.
🛡️ Security & Integrity: No outside script can access or corrupt the count variable. You have created a secure "black box" where the data and the logic are bundled together.

Real-World Case: Secure API Clients

In production environments (like building a Stripe or Firebase SDK), you often need to handle sensitive data like Access Tokens. Storing these in localStorage makes them vulnerable to XSS attacks.

The "Really Real-World" solution? Use a closure to create a private API client where the sensitive state is physically inaccessible from the global scope.

// This is how modern secure SDKs often handle internal state
function createApiClient(baseUrl, initialToken) {
  // SENSITIVE DATA: This lives only in the closure's "backpack"
  let accessToken = initialToken;

  return {
    async getData(endpoint) {
      console.log(`Fetching from ${baseUrl}${endpoint}...`);

      // The token is used internally here, but never exposed to the outside
      return fetch(`${baseUrl}${endpoint}`, {
        headers: { Authorization: `Bearer ${accessToken}` },
      });
    },
    updateToken(newToken) {
      accessToken = newToken; // Update the private memory safely
    },
  };
}

const client = createApiClient('https://api.mybank.com', 'your_initial_token');

// Works perfectly:
client.getData('/balance');

// SECURE: No rogue script can do this:
console.log(client.accessToken); // undefined
console.log(window.accessToken); // undefined

Why this matters: By using a closure, you've created a hard boundary. The only way to use that token is through the approved getData method. This is a standard pattern for building secure, encapsulated JavaScript libraries.

The Catch: Memory Leaks

A closure is like a "living connection" to its variables. Memory leaks happen when you leave these connections active after you no longer need them. "Similar to subscriptions, you need to sort of 'unsubscribe' from the closure to ensure that memory leakage is not present."

1. The "Zombie" Timer

When you use a closure inside a setInterval, the system keeps that "backpack" alive so it can run every second.

function startHeartbeat(data) {
  return setInterval(() => {
    console.log('Heartbeat for:', data);
  }, 1000);
}

let heartbeat = startHeartbeat('SensitiveData');

// CLEANUP:
clearInterval(heartbeat);
heartbeat = null;

2. The "Sticky" Event Listener

Global objects like window or document stay alive as long as the app is running. If you "glue" a closure to them, it will stay in memory forever unless you manually unstick it.

function trackScroll(componentName) {
  const handler = () => console.log(`Scrolling in ${componentName}`);
  window.addEventListener('scroll', handler);

  // Return a function to "unstick" the listener later
  return () => window.removeEventListener('scroll', handler);
}

const stopTracking = trackScroll('Header');

// When leaving the page:
stopTracking();

3. The "Forgotten" Global Reference

If you store a closure in a variable that lives for a long time, the memory stays locked. Simply tell the Garbage Collector: "I am done with this."

let secureVault = createSecureVault();
// ... later ...
secureVault = null;

Final thought: A closure isn't a memory leak by itself. A leak only happens when you forget to stop the process (Timer, Listener, or Reference) that keeps the closure alive.

Trade-offs

While closures are powerful, they aren't "free":

Memory Overhead: Variables in a closure's "backpack" are not garbage collected while the function exists. In high-performance apps, thousands of closures can cause "Memory Bloat."
Execution Speed: Creating a function inside another function is slightly slower than defining a function on a prototype.
Debugging Complexity: Inspecting private state is harder. You can't just console.log(client) to see the token; you have to use breakpoints.
Testability: If logic is too "private," it can be harder to unit test specific internal states without exposing them.

Conclusion

Closures allow you to write functions that are smart, private, and independent. They are the engine behind React Hooks, Secure SDKs, and elegant Encapsulation. Once you understand that a closure is just a function with a memory, you are good to go.

Disclaimer

The views expressed in this post are based on my personal learning journey. While closures are a standard feature, always ensure you follow your team's specific architectural patterns and performance guidelines to avoid unintended side effects.