How Code Actually Runs in Memory (Stack vs. Heap)

When we’re coding, we usually think in terms of logic: “I’m calling this function” or “I’m creating this variable.” But the computer doesn’t care about your logic. It only cares about memory.

Think of memory as a massive grid of empty boxes. Everything you write : every number, every giant list of users, every function has to sit in one of those boxes while the program is running.

But here’s the trick: the computer splits those boxes into two different zones.

1. The Stack (For the quick, simple stuff)
2. The Heap (For the big, messy stuff)

If you get how these two work, you’ll suddenly understand why some bugs happen and why your code behaves the way it does.

The Stack: The “In-and-Out” Zone

The Stack is for simple, small data. Things like:

• Numbers (10, 5.5)
• Booleans (true/false)
• The “address” of where a bigger object is hiding.

The most important thing about the Stack is that it’s fast and tidy. When a function finishes running, the Stack just “drops” everything that was inside it. It cleans up after itself instantly.

The Copy Rule: When you set let b = a with a simple number, the Stack literally grabs a new box and puts a fresh copy of that number inside.

let a = 10;
let b = a; // 'b' gets its own 10. They are strangers now.
b = 20; 
console.log(a); // Still 10.

The Heap: The “Warehouse”

The Heap is for the heavy lifters: Objects and Arrays.

These things can grow, shrink, and get complicated. They are too “heavy” for the Stack to manage comfortably. So, the computer puts the actual data in the Heap (the warehouse) and just hands the Stack a little sticky note with the address (a pointer).

The Shared Rule: When you “copy” an object, you aren’t copying the data. You are just copying the sticky note with the address on it.

let user = { name: "Faisal" };
let admin = user; // You didn't copy the person, just the address to find them.
admin.name = "Alok";
console.log(user.name); // "Alok"

Why did user change? Because both variables are looking at the exact same box in the Warehouse (Heap). You changed the contents of the box, not the sticky note.

Why should you care?

This isn’t just “computer science trivia.” This is why your code breaks in production.

1. The “Accidental Change” Bug

If you pass an object into a function and change a property inside that function, you are changing the original object. If you do that with a number, the original stays safe.

Rule of thumb: Numbers and Booleans are safe. Objects and Arrays are “shared.”

2. Cleaning up (Memory Leaks)

Because the Stack cleans itself up automatically, it’s hard to mess up. But the Heap? The Heap needs a “Garbage Collector” to come by and see if anyone is still using those boxes. If you keep accidentally leaving references to big objects you don’t need anymore, the Heap fills up, and your app crashes.

3. Real Copies vs. Fake Copies

If you actually want a different object that won’t mess with the original, you have to “spread” it into a new one: let copy = { ...original }; This tells the computer: "Go to the warehouse, look at the original box, and create a brand new box with the same stuff inside."

The Takeaway

Next time you’re debugging, stop looking at the lines of code for a second and visualize the boxes:

• Is this a simple value? It’s sitting right there in the Stack. It’s a copy. No stress.
• Is this an Object or Array? It’s in the Heap. You’re just holding a map to it. If you change it, everyone else holding that same map will see the change too.