What Your Code Doesn’t Use Still Matters: Understanding Tree Shaking in JavaScript

At some point, you write less code… but your application doesn’t get smaller.

You remove functions.

You stop using certain utilities.

And yet, the bundle size barely changes.

It feels strange.

Because intuitively, unused code should disappear.

But in JavaScript, that only happens under certain conditions.

And when those conditions aren’t met…

the code stays.

The Illusion of “Unused”

Consider this:

import { add, subtract } from "./math"

But in your code, you only use:

add(2, 3)

So the question becomes:

What happens to subtract?

You might assume it’s gone.

But that assumption depends on something deeper—

whether the system can prove that it’s safe to remove it.

What Tree Shaking Really Is

Tree shaking is often described as removing unused code.

But that description is incomplete.

A more honest way to see it is:

Removing code that can be proven to have no effect.

That word matters.

Proven.

Because if there’s even a small chance that removing something could change behavior…

it stays.

Why Structure Determines What Can Be Removed

This is where ES Modules quietly change everything.

When you write:

import { add } from "./math"

You’re being explicit.

You’re saying:

“I only need this”

And because imports are static, tools can analyze your code before it runs.

They can trace:

• what is imported
• what is never used

And safely remove the rest.

This is what makes tree shaking possible.

When Certainty Disappears

Now compare that with:

import * as math from "./math"

At first glance, it feels similar.

You still only call:

math.add(2, 3)

But something subtle has changed.

You’re no longer requesting a specific piece.

You’re asking for the entire module as a single object.

And once everything is grouped like that…

certainty disappears.

The Problem With “Maybe”

From your perspective, it’s obvious that only add is used.

But from the bundler’s perspective, it has to consider possibilities:

const fn = "add"
math[fn](2, 3)

Or:

for (const key in math) {
  console.log(math[key])
}

Now every export might be accessed.

Not because it is—

but because it could be.

And that possibility is enough to stop tree shaking.

When Code Becomes Untouchable

There’s another layer to this.

Even if a function is never used…

if the module has side effects, it cannot be removed.

export const value = 1

console.log("hello")

That console.log runs when the module is loaded.

So removing the file would change behavior.

Which means it must stay.

Tree shaking doesn’t just ask:

“Is this used?”

It asks:

“Is it safe to remove?”

The Deeper Pattern

At this point, something becomes clear.

Tree shaking depends on structure.

Not just what you write—

but how predictable your code is.

The more explicit and static your code:

import { add } from "./math"

The easier it is to analyze.

The more dynamic and flexible:

import * as math from "./math"

The harder it becomes.

And when analysis becomes uncertain…

optimization stops.

A Shift in Perspective

It’s easy to think of bundlers as tools that simply “remove unused code”.

But they’re closer to something else.

They are cautious interpreters.

They don’t assume.

They don’t guess.

They only remove what they can guarantee is unnecessary.

A Final Thought

Unused code doesn’t disappear just because you don’t call it.

It disappears when your code is structured in a way that makes its absence safe.

And that changes how you think about writing JavaScript.

Not just in terms of what works—

but in terms of what can be understood.

Because in the end, tree shaking isn’t just about removing code.

It’s about writing code that can be clearly seen for what it is.