DEV Community: Manoj Khatri

Why Your JavaScript Objects Keep Changing (And It's Not a Bug)

Manoj Khatri — Tue, 10 Feb 2026 08:45:08 +0000

const user = { name: "Alice", role: "user" };
const admin = user;

admin.role = "admin";

console.log(user.role); // What do you think this logs?

If you guessed "user", welcome to the club. Most developers get this wrong at first.

The answer is "admin". And if that surprises you, you're about to learn something that will change how you write JavaScript forever.

This isn't some edge case or weird quirk. This is fundamental to how JavaScript works. Once you understand what's happening behind the scenes in something called "the stack" and "the heap" suddenly everything clicks.

Those bugs that seemed random? They make sense. Those React state issues? Crystal clear. Those confusing code reviews? Actually straightforward.

Let me show you the mental model that most tutorials skip.

The Code That Doesn't Make Sense

Here's something you might have written (or are about to write):

function createUser(template) {
  const newUser = template;
  newUser.id = generateId();
  return newUser;
}

const userTemplate = { name: "", role: "user", permissions: [] };

const alice = createUser(userTemplate);
alice.name = "Alice";

const bob = createUser(userTemplate);
bob.name = "Bob";

console.log(alice.name); // "Bob" ??? 😱

Wait, what? Alice's name changed when we created Bob?

This looks like a bug. The code seems perfectly logical. But it's working exactly as designed, we just don't have the right mental model yet.

The problem isn't the code. It's that objects live in a completely different place than we think.

The Mental Model You Actually Need

Here's what's really happening when JavaScript runs your code:

Think of JavaScript Memory Like a Restaurant

The Stack = The Order Board

Fast, temporary, organized
New orders go on top, completed orders get removed
Automatically cleared when done
Holds: function calls, variables, and pointers

The Heap = The Storage Room

Slower, permanent (until garbage collected), flexible
Stores the actual data
Accessed by reference (like a locker number)
Holds: objects, arrays, functions, most strings

When you write const user = { name: "Alice" }, here's what JavaScript does:

STACK                    HEAP
┌─────────────┐         ┌──────────────────┐
│ user: ──────┼────────>│ {                │
└─────────────┘         │   name: "Alice"  │
                        │ }                │
                        └──────────────────┘

The variable user lives on the stack and holds a pointer (memory address). The actual object lives on the heap.

This is the key insight: When you copy a variable, you're copying the pointer, not the object itself.

The Five "Bugs" That Aren't Actually Bugs

Once you understand stack vs heap, these confusing behaviors suddenly make perfect sense.

1. The Accidental Mutation

const settings = { theme: "dark", language: "en" };
const userPrefs = settings;      // Copies the POINTER, not the object
const adminPrefs = settings;     // Another copy of the SAME pointer

userPrefs.theme = "light";

console.log(adminPrefs.theme);   // "light" 😱

What's happening in memory:

STACK                           HEAP
┌──────────────────┐           ┌─────────────────┐
│ settings:    ────┼──┐        │ {               │
├──────────────────┤  ├───────>│   theme: "light"│
│ userPrefs:   ────┼──┤        │   language: "en"│
├──────────────────┤  │        │ }               │
│ adminPrefs:  ────┼──┘        └─────────────────┘
└──────────────────┘

All three variables point to the same object on the heap. When you change one, you change them all.

The fix:

const settings = { theme: "dark", language: "en" };
const userPrefs = { ...settings };    // NEW heap object
const adminPrefs = { ...settings };   // Another NEW heap object

userPrefs.theme = "light";
console.log(adminPrefs.theme);        // "dark" ✅

Now each variable points to its own object.

2. The Array Surprise

function addItem(list, item) {
  list.push(item);    // Mutates the original heap object
  return list;
}

const shoppingList = [1, 2, 3];
const newList = addItem(shoppingList, 4);

console.log(shoppingList);  // [1, 2, 3, 4] 😱

You returned the list, so it should be safe, right? Nope. push mutates the heap object that both variables point to.

The fix:

function addItem(list, item) {
  return [...list, item];  // Creates NEW heap object
}

const shoppingList = [1, 2, 3];
const newList = addItem(shoppingList, 4);

console.log(shoppingList);  // [1, 2, 3] ✅
console.log(newList);       // [1, 2, 3, 4] ✅

3. The Closure That Remembers

This one blows people's minds:

function createCounter() {
  let count = 0;

  return function increment() {
    count++;
    return count;
  };
}

const counter1 = createCounter();
const counter2 = createCounter();

console.log(counter1());  // 1
console.log(counter1());  // 2
console.log(counter2());  // 1  ← Why doesn't this show 3?

Here's the beautiful part: When createCounter() finishes, normally everything on the stack gets cleared. But count is captured by the returned function, so JavaScript moves it to the heap.

After calling createCounter() twice:

HEAP
┌─────────────────────────────┐
│ Closure 1: { count: 2 }     │ ← counter1 points here
├─────────────────────────────┤
│ Closure 2: { count: 1 }     │ ← counter2 points here
└─────────────────────────────┘

Each function gets its own heap object with its own count. They don't interfere because they're pointing to different places in memory.

4. The `const` Confusion

const user = { name: "Alice" };

user = { name: "Bob" };     // ❌ Error: Assignment to constant variable

user.name = "Bob";          // ✅ This works fine!

A lot of people think const means "immutable." It doesn't.

const means you can't reassign the pointer (on the stack). But you can absolutely mutate the object (on the heap).

STACK              HEAP
┌────────┐        ┌──────────────┐
│ user ──┼───────>│ { name: ... }│ ← You CAN change this
└────────┘        └──────────────┘
     ↑
     └── You CANNOT change this pointer

5. The React State Mystery

If you've ever wondered why this doesn't work in React:

// ❌ This won't trigger a re-render
const [user, setUser] = useState({ name: "Alice" });

function updateName() {
  user.name = "Bob";      // Mutates heap object
  setUser(user);          // Same pointer! React sees no change
}

// ✅ This works
function updateName() {
  setUser({ ...user, name: "Bob" });  // NEW heap object, NEW pointer
}

React compares pointers, not object contents. If the pointer hasn't changed, React assumes nothing changed. This is why immutability is so important in React, you need to create new objects to trigger updates.

Try This Right Now

Open your browser console and run this experiment:

// Experiment 1: Primitives vs Objects
let a = 5;
let b = a;
b = 10;
console.log(a);  // Predict: ___

const x = { value: 5 };
const y = x;
y.value = 10;
console.log(x.value);  // Predict: ___

// Experiment 2: Arrays
const arr1 = [1, 2, 3];
const arr2 = arr1;
const arr3 = [...arr1];

arr2.push(4);

console.log(arr1);  // Predict: ___
console.log(arr3);  // Predict: ___

// Experiment 3: The Tricky One
const original = { 
  name: "Alice", 
  address: { city: "NYC" } 
};

const copy = { ...original };
copy.address.city = "LA";

console.log(original.address.city);  // Predict: ___

Answers:

5 (primitives copy by value - a and b are completely separate)
10 (objects share the same heap reference - x and y point to the same place)
[1, 2, 3, 4] and [1, 2, 3] (spread creates a new array, but arr2 shares a reference with arr1)
"LA" (gotcha! Spread only copies the top level; nested objects still share references)

That last one catches a lot of people. Spread operator does a shallow copy, not a deep copy.

When This Actually Matters: Performance

Understanding stack vs heap isn't just about preventing bugs. It can make your code significantly faster:

// 🐌 Slow: Creates 1 million heap objects
function processDataSlow(items) {
  for (let i = 0; i < 1_000_000; i++) {
    const temp = { index: i, value: items[i] };
    doSomething(temp);
  }
}

// ⚡ Fast: Reuses one heap object
function processDataFast(items) {
  const temp = { index: 0, value: null };
  for (let i = 0; i < 1_000_000; i++) {
    temp.index = i;
    temp.value = items[i];
    doSomething(temp);
  }
}

In benchmarks, the fast version runs 3-5x faster because:

Fewer garbage collection pauses
Better CPU cache utilization
Less memory allocation overhead

But here's the thing: Don't prematurely optimize. Use immutability by default (it prevents bugs), and only optimize hot paths when performance actually matters.

The Mental Model Cheat Sheet

┌─────────────────────────────────────────────────────────────┐
│                    ASSIGNMENT vs MUTATION                    │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ASSIGNMENT (changes the pointer)                           │
│  ✗ Not allowed with const                                   │
│  ✓ Creates new stack entry                                  │
│                                                              │
│    let x = { a: 1 };                                        │
│    x = { a: 2 };        ← Assignment                        │
│                                                              │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  MUTATION (changes the heap object)                         │
│  ✓ Allowed with const                                       │
│  ✗ Affects all references                                   │
│                                                              │
│    const x = { a: 1 };                                      │
│    x.a = 2;             ← Mutation                          │
│                                                              │
└─────────────────────────────────────────────────────────────┘

How to Write Better Code Starting Tomorrow

1. Default to creating new objects

// Instead of mutating
user.name = "Bob";

// Create new objects
const updatedUser = { ...user, name: "Bob" };

2. Know which array methods mutate

// ❌ These mutate the original array
push, pop, shift, unshift, splice, sort, reverse

// ✅ These return new arrays
concat, slice, map, filter, reduce, toSorted, toReversed

3. Be careful with nested objects

// Shallow copy doesn't protect nested objects!
const copy = { ...original };

// For deep copies:
const deepCopy = structuredClone(original);  // Modern browsers
// or
const deepCopy = JSON.parse(JSON.stringify(original));  // Quick solution

4. Use TypeScript for better safety

// TypeScript can help catch mutations
interface User {
  readonly name: string;
  readonly role: string;
}

const user: User = { name: "Alice", role: "user" };
user.name = "Bob";  // ❌ TypeScript error: Cannot assign to 'name'

5. Enable ESLint rules

// Add to your .eslintrc
{
  "rules": {
    "no-param-reassign": "error"  // Warns about parameter mutations
  }
}

Understanding Object Equality

Here's something that confuses developers all the time:

const a = { x: 1 };
const b = { x: 1 };
const c = a;

console.log(a === b);  // false
console.log(a === c);  // true

Why is a === b false when they look identical?

Both === and == compare pointers, not object contents. Even though a and b have the same properties and values, they're different objects on the heap. They occupy different memory locations.

Meanwhile, a === c is true because c = a copied the pointer. Both a and c point to the exact same heap object.

So how do you actually compare object contents?

For simple objects, you can use:

JSON.stringify(a) === JSON.stringify(b)  // true

For complex objects with methods, dates, or circular references, use a library like Lodash:

import _ from 'lodash';

_.isEqual(a, b)  // true

This understanding is crucial when working with React state, Redux reducers, or any code that depends on detecting changes in objects.

Common Misconceptions Cleared Up

"Primitives are always on the stack"

Not quite. Primitives in objects or closures live on the heap. JavaScript is smart about where to store things.

"Objects are slow because heap"

Modern engines optimize heavily. The performance difference is negligible for normal code. Don't micro-optimize based on this.

"const means the object is immutable"

Nope. const prevents reassignment of the variable, not mutation of the object it points to.

"Spread operator deep copies objects"

It's shallow only. Nested objects still share references.

Understanding stack vs heap isn't about memorizing rules. It's about building an accurate mental model of what JavaScript is actually doing when your code runs.

Once you have that model, the "bugs" aren't mysterious anymore. They're predictable. And predictable means fixable.

Why C++ Never Ran the Web: The $0.00 Secret of JavaScript’s Success

Manoj Khatri — Mon, 09 Feb 2026 11:33:02 +0000

Why C++ Never Ran the Web: The $0.00 Secret of JavaScript’s Success

How a "featherweight" scripting language defeated the world’s most powerful programming language to own the internet.

It’s 1995. You’ve got 8MB of RAM, a 100MHz CPU, and a single cat photo taking three minutes to load. In this era of digital "Wild West," the heavyweights of programming used C++. It was the language of power, the language of the elite. But when the web needed a brain, Brendan Eich developed JavaScript in just ten days.

Why did the world choose a "toy" language over a powerhouse? The answer lies in a high-stakes battle of hardware limits, security risks, and a philosophy that prioritized the human over the machine.

1. JavaScript vs C++: The Security "Sandbox"

C++ is like a Master Key. It gives developers low-level control over a computer's memory and system calls. While that power is great for building an OS, it’s a death sentence for a web browser.

Imagine visiting a random website and giving it the power to:

Access the File System: A malicious site could silently scan your drive for passwords.txt.
Execute System Calls: One line of code — system("format C:"); — could wipe your entire digital life.

This is why JavaScript was built with a Sandbox architecture. Unlike the "unrestricted" nature of C++, JS lives inside a glass box. It can change the color of a button, but it is physically barred from touching your personal files. It offered the world interaction without the risk.

2. The Battle of the Specs: 8MB RAM vs. The World

Memory and speed were one thing, but running a complex C++ runtime on a 1995 PC was an impossible task. We often forget how fragile our early hardware truly was.

Spec	1995 Home PC	Modern Smartphone
RAM	8 MB	8 GB - 12 GB
CPU Speed	100 MHz	3.0 GHz+
Storage	500 MB	256 GB+

The Takeaway: In 1995, C++ was a "Heavyweight" engine. JavaScript was a "Featherweight" script that could run on weak machines without causing the dreaded Blue Screen of Death.

3. Delivery Efficiency: The Postman vs. The Helicopter

Hardware was a bottleneck—but delivering code over a 56kbps modem? That was a challenge JavaScript solved elegantly.

To run C++, you usually need to download a pre-compiled "binary" file. On a slow dial-up connection, downloading a 2MB binary just to see a menu animation would take ten minutes.

JavaScript, however, acts like the Postman. It is sent as raw, simple text. The browser reads it and executes it instantly. It was the only way to deliver logic over the narrow "pipes" of the early internet.

4. Forgiving the Human: Developer Simplicity

C++ is a perfectionist. If you forget a single semicolon ; or mismanage a byte of memory, the whole system crashes with a "Segmentation Fault."

But the early web wasn't built by software engineers; it was built by hobbyists — people who were just learning what a <table> tag was. JavaScript was designed to be Forgiving. If your code is a bit messy, the browser tries to understand your intent rather than shutting down.

Most importantly, it introduced Automatic Garbage Collection.

In C++, you have to manually "clean up" memory. If you forget, your computer freezes. JavaScript’s engine acts like a smart assistant, following you around and cleaning up your code’s mess automatically.

The Lesson Learned: Why It Still Matters

Today, we have WebAssembly (Wasm), which finally allows languages like C++ to run in the browser. But even now, it runs inside the same "Sandbox" that JavaScript pioneered.

JavaScript didn't win because it was the most "powerful" language. It won because it prioritized three things:

User Safety: Interaction without the fear of viruses.
Lightweight Execution: Running on the hardware people actually owned.
Developer Simplicity: Making code accessible to the masses.

In a world of limited resources, being light and safe beats being fast and dangerous every single time.

DEV Community: Manoj Khatri

Why Your JavaScript Objects Keep Changing (And It's Not a Bug)

The Code That Doesn't Make Sense

The Mental Model You Actually Need

Think of JavaScript Memory Like a Restaurant

The Five "Bugs" That Aren't Actually Bugs

1. The Accidental Mutation

2. The Array Surprise

3. The Closure That Remembers

4. The const Confusion

5. The React State Mystery

Try This Right Now

When This Actually Matters: Performance

The Mental Model Cheat Sheet

How to Write Better Code Starting Tomorrow

Understanding Object Equality

Common Misconceptions Cleared Up

Why C++ Never Ran the Web: The $0.00 Secret of JavaScript’s Success

Why C++ Never Ran the Web: The $0.00 Secret of JavaScript’s Success

How a "featherweight" scripting language defeated the world’s most powerful programming language to own the internet.

1. JavaScript vs C++: The Security "Sandbox"

2. The Battle of the Specs: 8MB RAM vs. The World

3. Delivery Efficiency: The Postman vs. The Helicopter

4. Forgiving the Human: Developer Simplicity

The Lesson Learned: Why It Still Matters

4. The `const` Confusion