By now, you're probably comfortable writing JavaScript modules and using import and export. It feels clean. But if you've tried to run a complex project directly in the browser using type="module", you've likely hit a wall. You start seeing a waterfall of network requests in your DevTools, or you realize that importing a heavy library from an npm package doesn't "just work" without a CDN link. This is where bundling comes in.

The Script Tag Nightmare

In the early days—or if you're taking the naive approach today—you'd just stack <script> tags in your HTML. Imagine we're building a weather dashboard. You need Chart.js for the temperature graphs and lodash for some data manipulation. Your HTML looks like this:

<script src="js/vendor/lodash.min.js"></script>
<script src="js/vendor/chart.min.js"></script>
<script src="js/api.js"></script>
<script src="js/ui.js"></script>
<script src="js/app.js"></script>

This works for a tiny project, but it's a ticking time bomb. The biggest issue is execution order. If ui.js depends on a function in api.js, and you accidentally swap those lines, the whole app crashes with a ReferenceError. Then there's the "global scope pollution" problem. Every one of those scripts is dumping variables into the window object, making it incredibly easy to accidentally overwrite a variable and spend three hours debugging a ghost in the machine.

Solving the Graph with Bundlers

Instead of telling the browser which files to load and in what order, we use a bundler like Webpack or Vite. I like to think of a bundler as a map-maker. You give it one single entry point—usually main.js—and it follows the import statements to build a "dependency graph." It figures out that app.js needs ui.js, which needs Chart.js, and it stitches them together into one or two highly optimized files.

The trade-off here is that you've introduced a "build step." You can't just double-click index.html and see your changes anymore; you have to run a command like npm run dev. To me, this is a bargain. In exchange for that small overhead, you get "tree-shaking." If you only use one function from a massive library like lodash, the bundler can actually strip out the rest of the library so your users aren't downloading 50KB of code they'll never execute.

Webpack vs. Vite: The Heavy Lifter and the Speedster

You'll hear these two names constantly. Webpack has been the industry standard for years. It's incredibly powerful and can be configured to do almost anything, but that power comes with a steep learning curve. Its configuration files can become monsters that require a full-time engineer to maintain. I still use it for legacy projects or highly custom builds, but for most new work, it feels like overkill.

Vite (French for "fast") is the modern alternative. It takes a different approach by leveraging native ES modules during development. Instead of bundling everything every time you save a file, it only serves the module that changed. The result? Your page updates almost instantly, regardless of how large the project is. When you're ready for production, Vite uses Rollup under the hood to create a tight, optimized bundle. If you're starting a project today, start with Vite. Your sanity will thank you.

📋 Practical Task

Migrating the Weather Analytics Dashboard to Vite

You have been handed a "legacy" weather project that currently relies on five separate script tags in the HTML file and a few local JS files using global variables. Your task is to modernize this setup.

• Initialize a new Vite project in the root directory using npm create vite@latest . (selecting Vanilla JS).
• Move the existing logic from the separate script files into a modular structure.
• Convert the global variable dependencies into import and export statements.
• Install chart.js via npm instead of using the <script> tag.
• Verify that the dashboard still renders the temperature graph correctly when running npm run dev.