DEV Community: Naba Zehra

Value vs Reference

Naba Zehra — Mon, 06 Jul 2026 16:42:44 +0000

Primitives vs Objects

In the previous chapter, we learned why changing copy can unexpectedly change user.

The reason was simple:

Both variables were pointing to the same object in memory.

But that raises an interesting question.

Why does this happen with objects, but not with strings?

Take a look at this example:

let firstName = "Aline";
let copy = firstName;

copy = "Ali";

console.log(firstName);

What do you think the output will be?

If you said:

"Aline"

you're absolutely right.

Changing copy doesn't affect firstName.

Now compare that with an object:

const user = {
  name: "alina"
};

const copy = user;

copy.name = "Ali";

console.log(user.name);

This time the output is:

"Ali"

Wait a second.

Why are these examples behaving differently?

In both cases we created a copy.

In both cases we changed the copy.

Yet one leaves the original value untouched, while the other changes it.

At first glance, JavaScript seems inconsistent.

But once you understand the difference between primitive values and objects, everything starts to make sense.

Let's investigate.

Meet the Primitive Values

Before We Continue, What Does "Primitive" Actually Mean?

We've been using the word primitive, but what does it actually mean?

In simple terms, a primitive is a single value.

It isn't made up of smaller values.

For example:

const name = "Aline";

Each variable contains one simple value

A string.

A number.

A boolean.

Nothing more.

Types

JavaScript has seven primitive types:

These include:

String
Number
Boolean
Undefined
Null
Symbol
BigInt

These values are simple.

JavaScript can store them directly.

When we write:

let a = "alina";
let b = a;

JavaScript copies the actual value.

a ───► "alina"
b ───► "alina"

Notice something important.

Both variables have their own copy.

There is no connection between them.

So when we execute:

b = "Ali";

JavaScript simply changes the value inside b.

a ───► "alina"
b ───► "Ali"

Nothing happens to a.

This behavior is called copy by value.

Objects Play By Different Rules

Now let's revisit our earlier example.

const user = {
  name: "Alina"
};

const copy = user;

Unlike strings and numbers, objects are not copied directly.

Instead, JavaScript copies a reference.

user ───► Object

copy ───► Same Object

Both variables point to the same object.

That's why changing the object through one variable affects the other.

copy.name = "Ali";

The object changes.

Since both variables point to it, both variables see the update.

This behavior is called copy by reference.

A Simple Rule To Remember

Whenever you're confused, ask yourself one question:

Am I working with a primitive value or an object?

If it's a primitive:

const a = "Hello";
const b = a;

JavaScript copies the value.

If it's an object:

const a = {};
const b = a;

JavaScript copies the reference.

Meet the Second Category: Non-Primitive Types Or Objects

So far, we've talked about primitive values.

But not every value in JavaScript is a primitive.

Whenever you need to store multiple pieces of information together, JavaScript gives you objects.

const user = {
  name: "Alina",
  age: 15
};

Unlike primitives, objects can contain multiple values and even other objects.

Arrays and functions also belong to this category.

const skills = ["JavaScript", "React"];

function greet() {
  console.log("Hello");
}

console.log("typeof skills",typeof skills)
console.log("typeof greet",typeof greet)
console.log("greet",greet instanceof Object)

Output

Object
function
true

At this point, we've uncovered something interesting.

Functions aren't just pieces of code that can be executed.

They're also objects.

function greet() {}

console.log(greet instanceof Object); // true

That might seem strange at first, but it opens the door to some fascinating questions.

How can something be both a function and an object?

What special powers do functions have that regular objects don't?

And why does JavaScript treat them differently?

Let's find out.

In the next chapter, we'll take a closer look at functions and discover what actually makes them special.

Memory And References

Naba Zehra — Sun, 28 Jun 2026 16:42:44 +0000

Introduction

Many JavaScript developers know that objects are copied by reference, but few understand what that actually means.

The Problem

Consider the following code:

const user = {
  name: "Aline"
};

const copy = user;

copy.name = "Ali";

Why Does Changing `copy` Also Change `user`?

Imagine you're working on a production application.

You create a copy of an object so you can safely modify it.

const user = {
  name: "Aline"
};

const copy = user;

copy.name = "Ali";

console.log(user.name);

What do you expect to see?

Is your answer is:

"Aline"

After all, we changed copy, not user.

But JavaScript prints:

"Ali"

Wait...

How did changing copy affect user?

Did JavaScript secretly update both variables?

Did it create some hidden connection between them?

To answer that question, we need to look inside JavaScript's memory.

Let's Explore

When JavaScript executes:

const user = {
  name: "Aline"
};

it creates an object somewhere in memory.

For simplicity, imagine JavaScript stores that object at address 0x001.

Heap

0x001
┌─────────────┐
│{            │
│ name:Aline  │
│}            │
└─────────────┘

The variable itself is stored separately.

Instead of storing the entire object, it stores only the object's address.

Stack

user ──────► 0x001

Think of it like a house address.

The object is the house.

The variable only stores the address of that house.

The Mistake We Make

When they see:

const copy = user;

many of you imagine this:

user ──────► Object A

copy ──────► Object B

Two separate objects.

Two separate locations in memory.

But that's not what happens.

JavaScript does not create a new object.

It simply copies the address.

Stack

user ──────► 0x001
copy ──────► 0x001

Both variables now point to exactly the same object.

There is only one object in memory.

The Moment Everything Makes Sense

Now JavaScript executes:

copy.name = "Ali";

It follows the address stored inside copy.

copy ──────► 0x001

and updates the object found there.

Heap

0x001
┌─────────────┐
│ {           │
│ name:Ali    │
│ }           │
└─────────────┘

But user points to that exact same object.

user ──────► 0x001

So when we read:

console.log(user.name);

JavaScript finds:

"Ali"

Suddenly the behavior is no longer strange.

There were never two objects.

There was only one.

Creating a New Object

So how do we create a new object?

Most of use the spread operator.

const copy = {
  ...user
};

Now JavaScript creates a second object.

Stack

user ──────► 0x001
copy ──────► 0x002

Heap

0x001               0x002

{                    {
  name:"Aline"          name:"Aline"
}                    }

Perfect.

Problem solved.

Or is it not?

The Hidden Trap

Let's make the object slightly more realistic.

const user = {
  name: "Aline",
  address: {
    city: "Karachi"
  }
};

const copy = {
  ...user
};

Question:

What happens if we execute:

copy.address.city = "Lahore";

Will user.address.city stay "Karachi"?

Most people confidently answer:

Yes, because we created a copy.

Unfortunately, JavaScript has another surprise waiting for us.

Looking Deeper Into Memory

This time the memory looks like this:

Stack

user ──────► 0x001
copy ──────► 0x002

Heap

0x001
{
  name:"Aline",
  address ───► 0x100
}

0x002
{
  name:"Aline",
  address ───► 0x100
}

0x100
{
  city:"Karachi"
}

Notice something interesting.

The outer objects are different.

0x001 ≠ 0x002

But the nested object is shared.

address ───► 0x100

Both objects point to the same nested object.

This is called a shallow copy.

The first level is copied.

Nested objects are not.

The Bug Appears

Now JavaScript executes:

copy.address.city = "Lahore";

It follows:

copy
 ↓
0x002
 ↓
address
 ↓
0x100

and updates the shared object.

0x100
{
  city:"Lahore"
}

Since user.address also points to 0x100, it sees the update too.

console.log(user.address.city);

Output:

"Lahore"

Even though we never modified user.

Why `structuredClone()` Exists

We kept running into this problem.

They wanted a copy that duplicated everything.

Not just the first level.

Not just the outer object.

Everything.

That's why JavaScript introduced:

const copy = structuredClone(user);

Now JavaScript creates completely separate nested objects.

user ──────► 0x001
copy ──────► 0x002


0x001.address ──────► 0x100

0x002.address ──────► 0x200

Different outer objects.

Different nested objects.

No shared references.

No accidental mutations.

No surprises.

And that's the real difference between a shallow copy and a deep copy.

Quick Challenge

Without running the code, predict the output:


js
const user = {
  profile: {
    city: "Karachi"
  }
};

const copy = { ...user };

copy.profile.city = "Lahore";

console.log(user.profile.city);

DEV Community: Naba Zehra

Value vs Reference

Primitives vs Objects

Meet the Primitive Values

Before We Continue, What Does "Primitive" Actually Mean?

Types

Objects Play By Different Rules

A Simple Rule To Remember

Meet the Second Category: Non-Primitive Types Or Objects

Output

Memory And References

Introduction

The Problem

Why Does Changing copy Also Change user?

Let's Explore

Heap

Stack

The Mistake We Make

Stack

The Moment Everything Makes Sense

Heap

Creating a New Object

Stack

Heap

The Hidden Trap

Looking Deeper Into Memory

Stack

Heap

The Bug Appears

Why structuredClone() Exists

Quick Challenge

Why Does Changing `copy` Also Change `user`?

Why `structuredClone()` Exists