Forem: Md. Isfar Uddin

Tree Shaking in JavaScript - A Practical Guide

Md. Isfar Uddin — Tue, 14 Oct 2025 18:06:00 +0000

Imagine you're building a web app and your production bundle is absolutely massive. Like, embarrassingly large.

You keep wondering: "Why am I shipping 500KB of JavaScript when my app only uses maybe 200KB of actual code?" It felt like I was sending my users an entire library when they only needed a single book.

That's when I realized—I wasn't using tree shaking properly. And man, was I missing out on some serious optimization!

What Even is Tree Shaking?

Okay, so tree shaking sounds fancy, but it's actually a simple concept. Imagine you're pruning a tree. You shake the branches, and all the dead leaves fall off. The healthy, green leaves stay attached. That's exactly what tree shaking does in JavaScript—it removes dead code (code you're not using) and keeps only the code your app actually needs.

The technical term is dead code elimination. During the build process, your bundler analyzes your code and says, "Hey, this function is never called anywhere. Let me remove it from the final bundle."

Boom. ✨ Your bundle gets smaller.

Why Should You Care?

I get it—you might think: "My app works fine, who cares about a few extra kilobytes?" But here's the thing:

Smaller bundles = Faster downloads. Think about someone on a 4G connection downloading your app. Every KB matters. A 500KB bundle vs. a 300KB bundle is literally 40% extra data transferred. That's noticeable. That's waiting. That's users closing your tab and going to a competitor.

Performance matters for business. Studies show that every 100ms delay in load time costs you users. Tree shaking isn't magic, but it helps.

It's free optimization. You don't have to rewrite your code. Your bundler does the work for you in production.

Pretty sweet, right?

The Problem with CommonJS (Why It Doesn't Work)

Here's where it gets tricky. Not all module systems support tree shaking. And this is where many developers make a big mistake.

You might write CommonJS code like this:

// utils.js
exports.add = (a, b) => a + b;
exports.multiply = (a, b) => a * b;
exports.subtract = (a, b) => a - b;
exports.divide = (a, b) => a / b;

Then in your app:

// app.js
const utils = require('./utils');
console.log(utils.add(5, 3)); // Only add!

Here's the problem: they only used add. But bundler still included everything! Why?

Because CommonJS is dynamic. The bundler can't look at require('./utils') and know exactly what you'll use. You might access utils.multiply at runtime through a variable or something sneaky. So bundlers play it safe and include the entire module.

It's like ordering a pizza but the restaurant insists on giving you the entire pizza box, the menu, the napkins, the garlic knots you didn't order... 🍕

// This is what ends up in your bundle
// even though you only used add()
exports.add = (a, b) => a + b;        ✅ Used
exports.multiply = (a, b) => a * b;   ❌ Dead code
exports.subtract = (a, b) => a - b;   ❌ Dead code
exports.divide = (a, b) => a / b;     ❌ Dead code

Frustrating, right?

ES6 Modules Are Different (And Way Better)

This is where ES6 modules shine. They're static, which means the bundler can analyze them at build time and figure out exactly what's needed.

// math.js (ES6)
export const add = (a, b) => a + b;
export const multiply = (a, b) => a * b;
export const subtract = (a, b) => a - b;
export const divide = (a, b) => a / b;

Now in your app:

// app.js
import { add } from './math';
console.log(add(5, 3));

The bundler sees: "Only add is imported. I can safely remove the others."

And it does. multiply, subtract, and divide never make it to the final bundle. 🎉

// This is what ends up in your bundle with tree shaking
export const add = (a, b) => a + b;        ✅ Used
// multiply, subtract, divide removed!

This is tree shaking in action. Clean. Efficient. Beautiful.

The `import *` Mistake (Don't Do This)

Many developers do this when they're learning:

import * as math from './math';
console.log(math.add(5, 3));

Looks clean, right? Super convenient! Wrong. ❌

When you import everything with *, you're basically telling the bundler: "I need ALL of these exports, I promise!" So tree shaking throws its hands up and says, "Fine, I'll include everything."

This is a common mistake when looking at bundles—finding hundreds of unused functions from libraries that were imported. It's like showing up to a party and inviting everyone on the guest list, even though you only know three people.

The right approach:

// Good ✅
import { add, subtract } from './math';
console.log(add(5, 3));
console.log(subtract(10, 3));

// Bad ❌
import * as math from './math';
console.log(math.add(5, 3));

Named imports are your friend. They let tree shaking do its job properly.

Side Effects Are Tricky (This One Caught Me Off Guard)

Here's something that catches many developers off guard. Consider a module that looks like this:

// logger.js
console.log("Logger started!");  // <-- Side effect!

export const log = (msg) => console.log(msg);
export const warn = (msg) => console.warn(msg);
export const error = (msg) => console.error(msg);

That console.log at the top? That's a side effect. It runs when the module loads, no matter what you import from it.

Now when you import just log:

import { log } from './logger';
log("Hello world");

The bundler thought: "I can't remove this module because it has a side effect. That console.log might be critical!"

So even though you don't use warn or error, they stayed in the bundle.

The fix? Move the side effect into a function:

// logger.js (Fixed!)
const initLogger = () => {
  console.log("Logger started!");
};

export const log = (msg) => console.log(msg);
export const warn = (msg) => console.warn(msg);
export const error = (msg) => console.error(msg);

// Call this only when you need it
initLogger();

Now if you don't import warn or error, they get removed. No side effects blocking the way! 🎯

How to Actually Enable Tree Shaking

If you're using Webpack, tree shaking happens automatically in production mode. But you can be explicit about it:

// webpack.config.js
module.exports = {
  mode: 'production',  // This enables tree shaking
  optimization: {
    usedExports: true,
    sideEffects: false
  }
};

Or tell it in your package.json:

{
  "name": "my-package",
  "sideEffects": false  // "I promise, no side effects!"
}

Rollup and Vite enable tree shaking by default in production builds. So if you're using those, you're already good to go.

Real Talk: Verify It Actually Works

Theory is nice, but you should always verify tree shaking is working in your project. Use webpack-bundle-analyzer to visualize your bundle:

npm install --save-dev webpack-bundle-analyzer

Then run it:

webpack-bundle-analyzer dist/main.js

It generates a cool visualization showing exactly what's in your bundle. You might be shocked when you first see it—there could be 10KB of unused code from libraries you completely forgot about!

It's like looking in your closet and realizing you've got clothes with the tags still on them from three years ago. Time to clean up! 🧹

Common Mistakes I Made (So You Don't Have To)

Mistake 1: Using `import *`

// Bad ❌
import * as lodash from 'lodash';
const debounced = lodash.debounce(myFunc, 1000);

You'd be bundling half the library. The better approach:

// Good ✅
import { debounce } from 'lodash';
const debounced = debounce(myFunc, 1000);

Result: Cut bundle size by ~40KB immediately.

Mistake 2: Forgetting Dependencies Have Dependencies

Library A imports from Library B, which imports from Library C. If you import anything from A, all of it stays in your bundle, even if you don't use it. It's a chain reaction.

This is why you see packages like lodash-es (ES6 version) being recommended—better tree shaking support!

Mistake 3: Not Using Production Builds

Tree shaking only happens in production. If you're checking your dev bundle, tree shaking hasn't run yet. Many developers spend hours debugging this issue before realizing that dev bundles are supposed to be large.

Mistake 4: Assuming All Libraries Support Tree Shaking

Not every package is built with ES6 modules. Some still use CommonJS. Check the package.json:

{
  "main": "dist/index.js",        // CommonJS - no tree shaking
  "module": "dist/index.es.js"    // ES6 - tree shaking works!
}

If there's no "module" field, tree shaking won't work for that package.

What Actually Happens During Tree Shaking

Your bundler does two things:

Marking phase: Traces through all your imports and marks everything that's actually used with a little checkmark ✅
Removal phase: Takes a deep breath and deletes everything that wasn't marked ❌

It's like walking through your codebase with a highlighter, marking everything you use, then having a cleanup crew throw away the rest.

The Bundle Size Transformation

Here's what could happen in your project:

Before tree shaking: 450KB
After named imports:  320KB
After removing *:     285KB
After package.json:   250KB

Result: 44% smaller! 🎉

That's the difference between a 5-second load and a 3-second load for users on slower connections.

The Bottom Line

Tree shaking is powerful because it's automatic. Once you understand the rules, it just works:

✅ Use ES6 modules (import/export)
✅ Import only what you need (named imports)
✅ Keep modules side-effect free
✅ Use production builds for shipping
✅ Check your bundle to verify it's working

That's it. Your bundler handles the rest.

If you refactor your imports and remove those import * statements, your production bundle could drop from 450KB to 250KB. That's real impact. That's real performance gains.

Give tree shaking a shot in your next project. Your users will thank you. Your lighthouse score will thank you. Your bundles will be lean and mean.

Have you had bundle size issues before? What did you do to fix it? Please drop a comment below and let's talk!

Also, go check your bundle with webpack-bundle-analyzer. I bet you'll find some surprises!

Happy coding! 🚀

Understanding Garbage Collection in JavaScript

Md. Isfar Uddin — Sun, 12 Oct 2025 21:02:29 +0000

What is Garbage Collection? 🗑️

Have you ever created a JavaScript application and wondered if all those objects and variables you create are cleaned up automatically? Or did you assume they just disappear into thin air once they're no longer used?

The truth is, JavaScript manages memory automatically through a process called garbage collection. But here's the interesting part—not all programming languages work this way. Some make you do the cleanup yourself!

Let me tell you a story that will help you understand why garbage collection matters and how it works behind the scenes.

The Restaurant Analogy 🍽️

Imagine two different restaurants with very different cleanup policies.

Restaurant A (Manual Cleanup): When you write compiled languages like C or C++, you're like a guest at this restaurant—you have to wash your own dishes when you're done eating. You allocate memory when you need it, and you have to manually deallocate it when you're done. Manual memory management is exhausting, error-prone, and easy to mess up.

Restaurant B (Automatic Cleanup): But JavaScript? JavaScript is like a fancy restaurant where a cleanup crew automatically comes through after you're done eating. You don't wash a single dish. The restaurant staff handles everything. The moment you stop using something, the cleanup crew notices and removes it from the table. This is exactly what JavaScript's garbage collection does—it automatically cleans up memory you're no longer using. Pretty nice, right?

Why Should You Actually Care? 🤔

Great question! While garbage collection makes JavaScript incredibly convenient, understanding how it works is crucial. Here's why: if you allocate memory without realizing when it gets cleaned up, you could face serious performance issues or even memory leaks that slow down your entire application.

Think of it like this—if you keep ordering pizza but never throw out the boxes, your house gets messy fast. Similarly, if your app keeps creating objects without understanding how they're cleaned up, things can go downhill quickly.

How JavaScript Manages Memory ⚙️

Languages like Go, Python, and Node.js all use automatic memory management systems. When you allocate memory in these environments, the runtime automatically cleans up unused memory. But here's the million-dollar question: how does it actually work?

Memory Graphs: The Foundation

JavaScript creates a graph structure to track memory allocation. Think of it like a network of connections—when an object is created, it gets tracked as part of this graph. The garbage collector uses this graph to understand which objects are still in use and which ones have become orphaned.

The Mark and Release Process 🔄

Garbage collection happens in three distinct phases. Let me break it down:

Phase 1: Scanning

The garbage collector walks through your memory graph like a detective, identifying all objects that are still being actively used by your code. It marks these objects as "alive."

Phase 2: Locking

Here's the important part—during this scan, the system gets locked. It's like putting a "Do Not Disturb" sign on your code. Nobody can touch or modify the memory while the collector is working. This pause is sometimes called a "stop-the-world" event.

Phase 3: Release

Once the scan is complete, all the unused and unreferenced objects get released. That memory becomes available again for future allocations. Your code resumes execution.

Real-World Code Patterns 💻

Basic: Nullifying References

The simplest way to free memory is to explicitly tell the garbage collector that you're done with an object. Set it to null so it becomes eligible for cleanup.

let user = { name: "John", age: 30 };
console.log(user.name); // Use the object

user = null; // Tell GC: this object is no longer needed
// Memory is now eligible for cleanup

Key Point: Explicitly nullifying variables signals to the garbage collector that memory can be reclaimed. This is the foundation of manual memory management in JavaScript.

Pattern 1: Event Listeners

❌ The Forgotten Event Listener - Memory Leak

Event listeners attached to DOM elements can prevent garbage collection if they're never removed. This is one of the most common memory leak sources in real applications.

class DataManager {
  constructor() {
    this.data = [];

    // Problem: This listener is NEVER removed
    document.addEventListener('click', () => {
      this.data.push(Math.random());
    });
  }
}

let manager = new DataManager();
manager = null; // Memory leak! Event listener still holds reference

The Problem: Even though you nullified manager, the anonymous event listener keeps the object alive in memory.

✅ Smart Event Listener Cleanup - Solution

Store the event handler as a class property so you can remove it later. This is the proper way to manage event listeners.

class DataManager {
  constructor() {
    this.data = [];

    // Store the handler so we can remove it later
    this.handleClick = () => {
      this.data.push(Math.random());
    };

    document.addEventListener('click', this.handleClick);
  }

  // Cleanup method: Always provide this!
  destroy() {
    document.removeEventListener('click', this.handleClick);
    this.data = null;
  }
}

let manager = new DataManager();
manager.destroy(); // Properly remove listener
manager = null; // Now memory IS freed!

The Solution: Always have a cleanup/destroy method that removes listeners before nullifying.

Pattern 2: Variable Scope

❌ Accidental Globals - Memory Leak

Forgetting let, const, or var creates global variables that never get garbage collected. This is a silent killer.

function processUserData() {
  // Oops! Missing 'const' or 'let'
  largeData = {
    name: "John",
    records: new Array(1000000).fill("data")
  };
}

processUserData();
// largeData is now GLOBAL and can NEVER be garbage collected
console.log(window.largeData); // It's here forever!

The Problem: Without proper declaration, variables leak into the global scope permanently.

✅ Scoped Variables - Solution

Always use let or const to keep variables within function or block scope. Once the function ends, the variable is eligible for garbage collection.

function processUserData() {
  // Use 'const' to keep it local
  const largeData = {
    name: "John",
    records: new Array(1000000).fill("data")
  };

  return largeData.name; // Extract what you need
}

const userName = processUserData();
// largeData automatically goes out of scope and gets cleaned up
console.log(userName); // "John"

The Solution: Always use const or let and keep data local to functions.

Pattern 3: Circular References

❌ Two Objects Holding Hands - Circular Reference

When two objects reference each other, older garbage collectors might not clean them up. Modern engines handle this, but it's still a bad pattern.

function createCircularRef() {
  let obj1 = { name: "Object 1" };
  let obj2 = { name: "Object 2" };

  // They point to each other (circular dependency)
  obj1.ref = obj2;
  obj2.ref = obj1;

  return obj1;
}

let circular = createCircularRef();
circular = null; // Might not be cleaned in older engines

The Problem: Circular references can confuse garbage collectors about whether objects are truly unused.

✅ Breaking the Cycle - Solution

Explicitly break circular references before setting objects to null. This guarantees garbage collection in all scenarios.

function createObjects() {
  let obj1 = { name: "Object 1" };
  let obj2 = { name: "Object 2" };

  obj1.ref = obj2;
  obj2.ref = obj1;

  return obj1;
}

let obj = createObjects();

// Cleanup: Break the circular reference
function cleanup(obj) {
  obj.ref.ref = null; // Break one direction
  obj.ref = null;     // Break the other
}

cleanup(obj);
obj = null; // Safe to garbage collect

The Solution: Explicitly nullify references before cleanup to break the cycle.

Pattern 4: React Components

✅ React Cleanup Pattern - Best Practice

In React, always return a cleanup function from useEffect to remove subscriptions, timers, and listeners when the component unmounts.

import React, { useEffect, useState } from 'react';

function UserList() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    // Subscribe to data updates
    const subscription = subscribeToUserUpdates((newUsers) => {
      setUsers(newUsers);
    });

    // Cleanup function runs when component unmounts
    return () => {
      subscription.unsubscribe(); // Remove subscription
      // This prevents memory leaks when user navigates away
    };
  }, []);

  return (
    <ul>
      {users.map(user => <li key={user.id}>{user.name}</li>)}
    </ul>
  );
}

export default UserList;

The Pattern: React's cleanup function is like the destroy() method. It's your safety net for memory management.

Common Misconceptions ❌

Myth: "I don't need to care about garbage collection because it's automatic."

Reality: While it's automatic, understanding it helps you avoid memory leaks. You should be mindful of:

Keeping unnecessary references to objects
Event listeners that aren't properly removed
Circular references that can prevent cleanup
Large objects lingering in global scope

How to Monitor Garbage Collection 📊

Modern browsers and Node.js provide tools to help you monitor garbage collection:

Chrome DevTools: Memory tab shows heap snapshots and allocation timelines
Node.js: Use --inspect flag and connect Chrome DevTools
Performance API: Track performance metrics including GC pauses

// Check memory usage in Node.js
const used = process.memoryUsage();
for (let key in used) {
  console.log(`${key} ${Math.round(used[key] / 1024 / 1024)} MB`);
}

Key Takeaways 💡

Garbage collection is automatic but understanding it makes you a better developer
Memory leaks still happen - usually from keeping unnecessary references
Performance matters - understand when and how GC pauses occur
Monitor your apps - use DevTools to profile and identify issues
Write clean code - remove event listeners, close connections, and nullify references you no longer need

Conclusion 🚀

Garbage collection is JavaScript's superpower—it handles the tedious work of memory management behind the scenes so you can focus on writing great code. Now that you understand how it works, you're equipped to write more efficient applications and avoid common pitfalls like memory leaks.

The next time your JavaScript app runs smoothly without any hiccups, remember there's a hardworking garbage collector cleaning up after you!

Want to learn more? Share your thoughts in the comments below, and don't forget to dive into your browser's DevTools to see garbage collection in action!

Happy coding! 🎉