One of the most common pieces of JavaScript you’ll find in modern codebases looks like this:

const nextState = {
  ...state,
  count: state.count + 1
}

React developers write it.

Redux developers write it.

Vue developers write it.

Angular developers write it.

Nearly every frontend framework encourages some variation of it.

It feels clean.

It feels immutable.

It feels modern.

It feels almost free.

But here’s the uncomfortable truth:

Object spread is often far more expensive than most developers realize.

This doesn’t mean object spread is bad.

It doesn’t mean immutability is bad.

It doesn’t mean you should stop using it.

But it does mean you should understand what it’s actually doing.

Because once you understand the cost, you start making much better engineering decisions.

The Illusion

When developers see:

const nextState = {
  ...state,
  count: state.count + 1
}

they often mentally model it as:

Take state
Change count
Done

But that’s not what happens.

JavaScript doesn’t magically update the object.

Instead it performs something conceptually closer to:

const nextState = {}

for (const key in state) {
  nextState[key] = state[key]
}

nextState.count =
  state.count + 1

Notice the difference.

We’re not updating.

We’re copying.

Every property.

Every time.

What Actually Happens

Consider:

const user = {
  id: 1,
  name: "John",
  email: "john@example.com"
}

const updatedUser = {
  ...user,
  active: true
}

Internally:

Allocate New Object
↓
Copy id
↓
Copy name
↓
Copy email
↓
Add active

For three properties?

Nobody cares.

For thousands of properties?

You probably should.

The Cost Grows With Size

Imagine:

const hugeObject = {
  ...
}

containing:

10,000 properties

Now:

{
  ...hugeObject,
  updated: true
}

must:

Allocate New Object
+
Copy 10,000 Properties
+
Add One Property

Just to change one value.

That’s not free.

The Famous Reduce Trap

This is one of the most common performance issues I see.

const usersById =
  users.reduce(
    (acc, user) => ({
      ...acc,
      [user.id]: user
    }),
    {}
  )

Looks elegant.

Looks immutable.

Looks functional.

Looks expensive.

Let’s see why.

Iteration 1

{}

Copy:

0 properties

Iteration 2

{
  1: user1
}

Copy:

1 property

Iteration 3

{
  1: user1,
  2: user2
}

Copy:

2 properties

Iteration 1000

Copy 999 properties

Total Work

What initially looks like:

O(n)

can become closer to:

O(n²)

because every iteration copies everything accumulated so far.

That is a very different performance profile.

The Loop Equivalent

Compare:

const usersById =
  users.reduce(
    (acc, user) => ({
      ...acc,
      [user.id]: user
    }),
    {}
  )

with:

const usersById = {}

for (const user of users) {
  usersById[user.id] = user
}

The loop:

Creates One Object
Mutates One Object
Performs One Pass

No repeated copies.

No repeated allocations.

No repeated garbage collection.

Why React Popularized Object Spread

This is where things get interesting.

React didn’t make object spread popular by accident.

React relies heavily on:

Reference Equality

Example:

if (
  previousState !== nextState
) {
  rerender()
}

This works beautifully when:

const nextState = {
  ...state,
  count: 1
}

because:

New Object
New Reference

React can instantly detect the change.

This is a great reason to use object spread.

But:

Useful
≠
Free

Deeply Nested Objects

This is where things get ugly.

Suppose:

const nextState = {
  ...state,
  user: {
    ...state.user,
    address: {
      ...state.user.address,
      city: "Dubai"
    }
  }
}

You’ve probably written something similar.

Maybe many times.

Let’s count.

Copy state
Copy user
Copy address
Update city

Multiple allocations.

Multiple copies.

For one change.

Why Immer Became Popular

This problem became so common that libraries emerged specifically to solve it.

One of the most popular is Immer.

Instead of:

const nextState = {
  ...state,
  user: {
    ...state.user,
    address: {
      ...state.user.address,
      city: "Dubai"
    }
  }
}

Immer allows:

draft.user.address.city =
  "Dubai"

while still producing an immutable result.

This dramatically improves readability.

Garbage Collection Matters

Most developers focus on CPU.

But memory matters too.

Every spread operation creates:

Temporary Objects

Those objects eventually become:

Garbage

Which means:

Garbage Collection

must clean them.

The larger the application becomes:

More Allocations
↓
More Garbage
↓
More GC Work

Sometimes the bottleneck isn’t computation.

It’s memory churn.

The Hidden Cost In State Management

Consider:

return {
  ...state,
  loading: true
}

Looks harmless.

Now imagine:

100 updates per second

across:

Multiple Stores
Multiple Components
Large State Trees

Suddenly those allocations become measurable.

Not catastrophic.

Just measurable.

And that’s the point.

When Object Spread Is Perfect

Let’s be fair.

Object spread solves real problems.

Example:

const updatedUser = {
  ...user,
  active: true
}

Clear.

Readable.

Predictable.

For small objects:

Use it.

Without hesitation.

When You Should Be Careful

Pay attention when you see:

Large Collections

Large State Trees

Reducers Executing Frequently

Performance-Critical Loops

This is where spread begins to matter.

Benchmark Mentality

One of the biggest mistakes developers make is assuming:

Spread Is Slow

Spread Is Fast

Both are wrong.

The correct answer is:

It Depends

How many properties?

How often?

How frequently is the code executed?

How large are the objects?

Engineering is always contextual.

Real World Example: API Processing

Bad:

const result =
  users.reduce(
    (acc, user) => ({
      ...acc,
      [user.id]: user
    }),
    {}
  )

Better:

const result = {}

for (const user of users) {
  result[user.id] = user
}

The second version scales significantly better.

Real World Example: React State

Good:

setUser({
  ...user,
  name: "John"
})

The object is small.

Readability wins.

Optimization would be pointless.

Real World Example: Deep Updates

Instead of:

{
  ...state,
  a: {
    ...state.a,
    b: {
      ...state.a.b,
      c: value
    }
  }
}

consider:

State normalization
Immer
Better state structure

Architecture often beats optimization.

Pros Of Object Spread

1. Readable

Intent is obvious.

2. Immutable

Reduces accidental mutations.

3. React-Friendly

Works perfectly with reference equality.

4. Predictable

Creates explicit state transitions.

5. Easy To Learn

Minimal cognitive overhead.

Cons Of Object Spread

1. Allocations

Every spread creates a new object.

2. Property Copying

The larger the object, the more expensive the copy.

3. Garbage Collection Pressure

Temporary objects accumulate.

4. Easy To Abuse In Reducers

Repeated spreads can become surprisingly expensive.

5. Deep Updates Become Ugly

Nested spreads quickly reduce readability.

The Real Lesson

The biggest mistake developers make with object spread is treating it as a free operation.

It isn’t.

The second biggest mistake is treating it as a bad operation.

It isn’t.

Object spread is a tool.

A very useful tool.

A very readable tool.

A very common tool.

But every immutable update has a cost.

The goal isn’t avoiding object spread.

The goal is understanding when its benefits outweigh its costs.

Because once you understand the tradeoff, you stop blindly copying objects.

And start making deliberate engineering decisions.

What’s Next?

In the next article we’ll discuss:

Composability Is The Real Superpower

Because after exploring:

Reduce
Transducers
Functors
FlatMap
Monads
RxJS
Event Sourcing

you’ll discover that all of them ultimately revolve around a single idea:

Composition

And that idea is far more important than any individual function.

About The Author

Hi, I’m Amrish Khan.

I enjoy building developer tools, exploring software architecture, and writing about the deeper ideas behind everyday programming concepts.

I’m also building Aruvix — a growing ecosystem of local-first developer tools designed to process data directly in the browser without unnecessary uploads.

Here’s a detailed blog on Aruvix:

https://dev.to/amrishkhan05/aruvix-the-ultimate-offline-first-developer-toolkit-e0i

You can follow my work and thoughts here:

Portfolio:
https://www.amrishkhan.dev

LinkedIn:
https://www.linkedin.com/in/amrishkhan

GitHub:
https://www.github.com/amrishkhan05

If you enjoyed this article, consider following for more deep dives into JavaScript, architecture, local-first software, and performance engineering.

The Hidden Cost of Object Spread

The Illusion

What Actually Happens

The Cost Grows With Size

The Famous Reduce Trap

Iteration 1

Iteration 2

Iteration 3

Iteration 1000

Total Work

The Loop Equivalent

Why React Popularized Object Spread

Deeply Nested Objects

Why Immer Became Popular

Garbage Collection Matters

The Hidden Cost In State Management

When Object Spread Is Perfect

When You Should Be Careful

Benchmark Mentality

Real World Example: API Processing

Real World Example: React State

Real World Example: Deep Updates

Pros Of Object Spread

1. Readable

2. Immutable

3. React-Friendly

4. Predictable

5. Easy To Learn

Cons Of Object Spread

1. Allocations

2. Property Copying

3. Garbage Collection Pressure

4. Easy To Abuse In Reducers

5. Deep Updates Become Ugly

The Real Lesson

What’s Next?

About The Author

Leave a Reply Cancel reply