DEV Community: Daniel Ledvina

Road to Senior #2: How Computers Think in Numbers

Daniel Ledvina — Mon, 25 May 2026 15:55:20 +0000

⏱️ Reading time: 7-9 minutes
🎯 Difficulty: Beginner - Intermediate
📂 Themes: Computer Science, Binary, Memory, Performance

What's inside?

🔍 The Problem — A CSS color that made me realize I understood nothing
⚡ Bits & Bytes — The two building blocks of everything
🔣 Hex & RGB — Why #FF0000 is red, and what those letters actually mean
🔤 ASCII & UTF-8 — How numbers become letters, emoji, and everything in between
🏗️ RAM, Cache & the Bus — Where data lives and how it moves
⚡ Interrupts & DMA — How hardware talks to software — and why it matters

🔍 The Problem

After publishing my first post about Stack and Heap, I felt like the foundation was solid.

I understood where data lives in memory. I understood why [] === [] returns false. References, garbage collection — the mental model clicked.

Then I opened DevTools. I was debugging a color issue and I saw this in the CSS:

background-color: #FF5733;

And I froze.

I type hex colors every day. I know #FF0000 is red. I know #FFFFFF is white. But why? What does FF actually mean? Why two characters? Why letters at all?

I realized I was using a notation I didn't understand, built on a number system I'd never properly learned, representing data stored in a format I'd never thought about.

So I went to the bottom. This is what I found.

⚡ Bits & Bytes

The smallest unit of information in a computer is a bit. Not a concept — a physical thing. An electrical signal on a wire. Either current flows (1) or it doesn't (0).

0 = off / false / no current
1 = on  / true  / current flows

Why only two states? An electrical signal has exactly two stable states — saturation (current flows = 1) and cutoff (no current = 0). Three states would be unreliable and hard to distinguish. Everything in computing is built on this constraint.

A single bit isn't useful on its own. So computers group them into bytes.

8 bits = 1 byte. Eight bits gives you 2⁸ = 256 different combinations — values from 0 to 255.

Why 255 and not 256? Because you count from zero:

2⁸ = 256 possibilities
0, 1, 2 ... 255 = 256 numbers total
maximum = 255 = 256 - 1

Why 8 bits? Three reasons that compounded into a standard:

256 values covers the entire ASCII table — English alphabet, digits, special characters
8 is a power of 2 (2³) — it divides cleanly into everything, and 8 bits = exactly 2 hex digits, no remainder
It became the hardware standard in the 1970s, and hardware standards are almost impossible to undo

💡 RAM doesn't address individual bits — it addresses bytes. Every memory address (0x4A2F) points to exactly one byte.

This connects directly to the previous post. A memory address on the Stack takes exactly 8 bytes — because 8 bytes matches the width of the 64-bit data bus. One transfer, one value. If a number were 9 bytes, you'd need two transfers. The whole system is designed to fit into one.

💡 Stack must know sizes in advance — that's why objects of unknown size go to the Heap. And now you know why the sizes are what they are.

🔣 Hex & RGB

Now we can actually answer the CSS question.

Binary is how computers store everything. But binary is terrible for humans to read:

The number 255 in binary:  11111111

Eight characters for a number most developers recognize instantly. Imagine reading memory addresses in binary — every address would be dozens of characters. Nobody could work like that.

So we use hexadecimal — base 16.

In our normal decimal system, each digit has 10 possible values (0–9). In hex, each digit has 16: the numbers 0–9, then the letters A–F (where A=10, B=11, up to F=15).

The reason hex exists is a single elegant fact: 4 bits = 2⁴ = exactly 16 combinations. One hex digit represents exactly 4 bits. Two hex digits represent exactly one byte. The math is perfect:

255 in binary: 11111111  ← 8 characters
255 in hex:    FF        ← 2 characters

Half the characters, same information, perfect alignment with the underlying bit structure. This is why you see hex everywhere data needs to be written compactly:

Memory address:  0x4A2F3C
Git commit hash: a3f4b2c
CSS color:       #FF5733

What `#FF5733` actually means

CSS colors use the format #RRGGBB. Red, Green, Blue — each represented by two hex characters, which means each is one byte, which means each can range from 0 to 255.

This is the RGB color model. Screens don't mix pigments — they mix light. Three channels of colored light: red, green, blue. Each channel says how bright that component shines, from 0 (completely off) to 255 (full intensity). Combine them in different proportions and you get any color.

#FF5733

FF = Red   → 255 (full intensity)
57 = Green → 87
33 = Blue  → 51

A warm orange-red. Full red, some green, a little blue.

#FF0000 → red 255, green 0,   blue 0   → pure red
#00FF00 → red 0,   green 255, blue 0   → pure green
#FFFFFF → all channels 255             → white
#000000 → all channels 0               → black

RGB is an additive model — more light means brighter, and all three at maximum is white. This is the opposite of paint or print (CMYK), where mixing colors gets darker.

Three channels × 1 byte each = 3 bytes = 24 bits. That's "24-bit color" — 2²⁴ = over 16 million possible colors, all encoded in a 6-character string.

🔤 ASCII & UTF-8

Hex explains colors. The same question applies to text.

A computer stores numbers. It has no concept of the letter A. So how does A appear on your screen?

The answer is a table everyone agreed to use.

ASCII (American Standard Code for Information Interchange) is a standard from 1963 that says: the number 65 means the letter A. Every OS, browser, and text editor implements this agreement. One byte per character, 128 characters total.

A = 65 = 0x41
a = 97 = 0x61

It worked perfectly — for English. Then the internet connected the rest of the world.

Unicode is the modern successor. It assigns a unique number to every character in every writing system humans have ever used — Latin, Arabic, Chinese, emoji. Over 1.1 million characters total.

UTF-8 (Unicode Transformation Format, 8-bit) is how Unicode numbers get stored as bytes. Its key feature is variable length — common characters take fewer bytes, rare ones take more:

Bytes	Examples
1	A, B, 0–9 (identical to ASCII)
2	á, é, č, ř
3	中, 日
4	😀, 🔥

UTF-16 (Unicode Transformation Format, 16-bit) uses 16-bit units instead of 8-bit. Characters above 65,535 — including most emoji — need two units back to back, called a surrogate pair.

💡 UTF-8 encodes characters 0–127 identically to ASCII — an old ASCII file is valid UTF-8 with no changes. UTF-16 doesn't have this compatibility. That's why UTF-8 took over the web.

🏗️ RAM, Cache & the Bus

We've covered how data is represented. Now let's look at where it lives and how it moves — because this is where the physical limits of performance come from.

My previous post talked about Stack and Heap as regions of RAM. But RAM itself sits inside a bigger picture.

The memory hierarchy

Not all memory is equal. The closer to the CPU, the faster — and the smaller:

L1 Cache  — ~64 KB    — ~4 nanoseconds   — inside each CPU core
L2 Cache  — ~1 MB     — ~12 nanoseconds  — inside CPU, per core
L3 Cache  — ~8–32 MB  — ~40 nanoseconds  — inside CPU, shared
RAM       — ~8–64 GB  — ~100 nanoseconds — outside CPU, on the motherboard

The CPU always searches L1 → L2 → L3 → RAM automatically. When it doesn't find data in cache, it fetches a block of ~64 bytes from RAM at once — not just the one byte it needs. If your data is sequential (like an array), the next elements are already loaded. If it's scattered (like a linked list), every step is a cache miss and a ~100 nanosecond penalty.

💡 Data travels between RAM and the CPU over the data bus — 64 bits (8 bytes) per cycle on a 64-bit system. One value, one transfer. The whole memory system is built around this boundary.

⚡ Interrupts & DMA

This last part took me by surprise. I expected it to be low-level hardware trivia. Instead it turned out to be the physical foundation of something every developer uses every day.

The clock

Every CPU has a crystal oscillator — a literal piece of quartz that vibrates at a precise frequency. Think of it as a metronome. Each beat is one clock cycle, and the CPU does exactly one thing per beat.

A 3 GHz processor runs 3 billion cycles per second. On every cycle, it executes one instruction — and checks a set of physical pins on the chip: the IRQ (Interrupt Request) pins.

How hardware gets the CPU's attention

Each IRQ pin is assigned to a device:

IRQ 0  → system timer
IRQ 1  → keyboard
IRQ 11 → network card
IRQ 14 → disk (SSD/HDD)

Normally, the pins carry 0V — silence. When a device needs attention, it raises its pin to 3.3V. The CPU finishes its current instruction, detects the signal, saves its state, looks up the correct handler in the Interrupt Vector Table, runs it, then resumes exactly where it left off.

Think of it like a doorbell. Without interrupts, you'd have to walk to the door every few seconds to check if anyone's there — that's polling, and it wastes enormous compute time on nothing. With interrupts, you just work until the bell rings.

💡 The CPU never stops mid-instruction. It always finishes what it's doing first — that's why interrupts aren't truly "instant."

DMA: moving data without the CPU

Think of it like a kitchen. The CPU is the head chef — it cooks. DMA is the assistant who runs to the warehouse, grabs the ingredients, and brings them to the counter. The chef doesn't stop cooking to fetch things. He just gets a tap on the shoulder when everything is ready.

Without DMA, the CPU would have to move every byte of data itself — and check constantly whether it's arrived yet:

// Without DMA — polling:
CPU: "Is the data ready?" → No
CPU: "Is the data ready?" → No
CPU: "Is the data ready?" → Yes → process it
// CPU is busy the entire time. Nothing else can run.

// With DMA:
CPU: "Here's the job, let me know when done" → continues working
DMA:  *transfers data independently*
DMA: "Done" → fires interrupt
CPU:  *handles result*
// CPU is free the entire time.

DMA is a dedicated chip on the motherboard. It moves data between RAM and devices over its own bus, independently. The CPU never touched the data — it just gets notified when it's ready.

Putting it all together

Hardware is not magic. The clock ticks, the pin changes voltage, the chip moves data, the CPU gets notified. That's it. Every abstraction we work with every day — languages, runtimes, frameworks — is built on top of these simple physical mechanisms.

Understanding this doesn't make you write better code overnight. But it changes how you think about it. When something feels like "just how it works," there's always a reason underneath. And the reason is usually simpler than you'd expect.

What I Know Now

I started with a hex color I didn't understand.

I ended up at the physics of how computers talk to their own hardware.

The chain is cleaner than I expected:

Everything is numbers — letters, colors, addresses, network data, all of it
Numbers are bytes — groups of 8 bits, the atomic unit of memory
Hex is shorthand — 2 characters = 1 byte, perfectly aligned with the bit structure
RGB is 3 bytes — one per color channel, 16 million colors from 24 bits
Text is a table — ASCII and UTF-8 map byte values to characters by agreement
Memory has layers — cache exists because the CPU is faster than the wires to RAM
Async is hardware — DMA + interrupts, not just a runtime feature

Next up: the Event Loop, Call Stack, and Task Queue — the full picture of how software is scheduled on top of everything above.

Part 2 of the Road to Senior series — documenting everything I'm learning on the way to becoming a senior developer.

← Part 1: Where Your Data Lives

Road to Senior #1: 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.

DEV Community: Daniel Ledvina

Road to Senior #2: How Computers Think in Numbers

What's inside?

🔍 The Problem

⚡ Bits & Bytes

🔣 Hex & RGB

What #FF5733 actually means

🔤 ASCII & UTF-8

🏗️ RAM, Cache & the Bus

The memory hierarchy

⚡ Interrupts & DMA

The clock

How hardware gets the CPU's attention

DMA: moving data without the CPU

Putting it all together

What I Know Now

Road to Senior #1: Where Your Data Lives

What's inside?

🔍 The Problem

📦 Stack & Heap — Where Your Data Actually Lives

The Stack

The Heap

The Key Insight

🔗 Value vs Reference Types

Value Types

Reference Types

The Fix — Create a New Reference

How === Actually Works

🔒 const and Object.freeze

What const Actually Does

What Object.freeze Does

The Catch — freeze is Shallow

Quick Summary

🧹 Garbage Collection — Where Memory Leaks Really Come From

The Fundamental Rule

How It Works — Mark-and-Sweep

When Does GC Run?

Memory Leaks — When GC Can't Help You

Why Angular Cares So Much About This

⚡ Change Detection — How Angular Uses Everything Above

The Core Question

Why Mutation Doesn't Work

What I Know Now

Closures made simple

What's inside?

The Definition

What are they for?

See it in action

❌ Before: The "Global Mess" approach

✅ After: The "Closure" approach

Real-World Case: Secure API Clients

The Catch: Memory Leaks

1. The "Zombie" Timer

2. The "Sticky" Event Listener

3. The "Forgotten" Global Reference

Trade-offs

Conclusion

Disclaimer

What `#FF5733` actually means