Day 5: Where Do Variables Actually Live?

Day 5. Today's topic sounded boring when sir said it: "stack and heap memory." I almost zoned out. Then ten minutes later I was staring at my screen going "WAIT, that's allowed?!"

I'm learning JavaScript in my web development course, and today we went UNDER the hood — where does JavaScript actually KEEP your variables?

Two neighborhoods in your RAM

Your computer's memory (RAM — sir even wrote "4 GB Ram" on the board) has two neighborhoods, and JavaScript uses both:

The Stack is like your work desk. Small, organized, fast. This is where JavaScript keeps the simple stuff — primitives. Numbers, strings, booleans. The actual VALUE sits right there on the desk.

The Heap is like a warehouse. Big, spacious, a bit messy. This is where the complicated stuff lives — objects, arrays, functions. But here's the twist: your variable doesn't hold the object. It holds the ADDRESS of the object. Like a slip of paper that says "go to warehouse shelf 6382."

The internet's best analogy for this (and I'm stealing it): it's like a house address. The house is the actual object sitting in the heap. The address written on paper is the reference your variable holds. And if two people have the SAME address written down? They both walk into the same house.

Remember that. It's about to matter a lot.

Copy by value: the photocopy

Let's start with the well-behaved case. Real code from my practice file:

let a = 10;
let b = a;
b = 30;
console.log(b);  // 30
console.log(a);  // 10

let b = a — you'd think b and a are now linked, right? Nope. With primitives, JavaScript makes a PHOTOCOPY. b gets its own independent copy of 10. Then b becomes 30, and a just sits there at 10, completely unbothered.

One more word from class: primitives are IMMUTABLE. Fancy word, simple meaning — the value itself can't be changed, only replaced. When you write a = 20, JavaScript doesn't edit the 10. It throws it away and puts 20 in its place. Like replacing a sugar cube, not reshaping it. (Sir literally drew sugar cubes on the board. I have the notebook to prove it.)

Copy by reference: the shared Google Doc

Now the same idea, but with an object. Same practice file:

let obj1 = {
    id: 20,
    name: "rohit"
};

let obj2 = obj1;
obj2.id = 30;

console.log(obj1);  // { id: 30, name: "rohit" }
console.log(obj2);  // { id: 30, name: "rohit" }

Read that output again. I changed obj2. But obj1 ALSO changed. I did NOT touch obj1!

That's the exact face I made.

Here's what happened, watch it unfold:

let obj2 = obj1 did NOT copy the object. It copied the ADDRESS. Now obj1 and obj2 both hold "@6382" — two slips of paper with the same warehouse address. There's still only ONE object in the heap.

So obj2.id = 30 walks into that one shared object and changes it. Then when you ask obj1 what's in there — surprise, it's 30 too. Because it's the same object!

The internet's perfect analogy: it's a shared Google Doc link. A photocopy (primitives) — you scribble on your copy, the original is fine. A shared doc link (objects) — you edit the doc, EVERYONE with the link sees the change. obj1 and obj2 both have the link.

Why should you care?

Because this bug has ended careers. Okay, slight exaggeration. But barely.

Imagine you're building a shopping cart. You copy the cart to make a "backup"... then the user removes an item from the real cart... and your backup loses it too. Because it was never a backup. It was the same cart with two names.

This is THE classic beginner bug. Now you know it exists before it bites you. You're welcome.

The fix? There are ways to make a REAL copy (spread operator and friends are coming on a future day). For today, just remember the rule:

Primitives → copied by value. Objects → copied by reference.

Or even shorter, straight from my notebook: "Primitive = copy milta hai. Non-primitive = reference milta hai."

---

Tomorrow: wherever day 6 takes us. The deeper we go, the more interesting it gets. See you there.