Webpack Explained: Bundling JavaScript for the Browser

Introduction

Browsers used to load one script tag at a time, and every file was global — a recipe for name collisions and slow pages. Modern JavaScript uses modules (the JavaScript modules concept), but browsers historically couldn't resolve hundreds of module files efficiently, and they certainly couldn't import CSS or images. Webpack solved this by bundling: it starts from an entry point, follows every import, and produces a small number of optimised files a browser can load.

Entry, output, and the dependency graph

Webpack's core idea is the dependency graph: starting from your entry file, it recursively follows every import and require, building a complete map of what your application needs:

// webpack.config.js
module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "bundle.js",
    path: __dirname + "/dist",
  },
};

Everything reachable from the entry ends up in the output; everything unreachable is left out (tree-shaking, in modern terms). That graph is also why Webpack can do code splitting — separating rarely-used code (like an admin panel) into a chunk loaded only when needed, so the first page load stays fast.

Loaders: teaching Webpack new file types

Out of the box, Webpack understands JavaScript. Everything else needs a loader — a small plugin that teaches it to transform a file type:

module: {
  rules: [
    { test: /\.css$/, use: ["style-loader", "css-loader"] },
    { test: /\.(png|jpg)$/, type: "asset/resource" },
  ],
},

With loaders, import "./styles.css" and import logo from "./logo.png" become ordinary code: CSS gets injected or extracted, images get hashed filenames for caching, and TypeScript or Sass gets compiled on the way in. This "everything is a module" philosophy is Webpack's real legacy — it taught the ecosystem to treat assets as part of the dependency graph, not as separate concerns.

The honest trade

Webpack is powerful and famously configuration-heavy: real-world configs run to hundreds of lines, and debugging a broken build can be genuinely hard. That complexity is exactly why Vite (the Vite post) took over new projects — it skips bundling during development entirely. But Webpack still runs a huge share of production sites, and understanding entry, loaders, and the dependency graph explains how nearly every build tool since has worked. Learn the concepts here, and every bundler after it makes sense faster.

Takeaway

Webpack builds a dependency graph from an entry point, loaders teach it every file type, and the output is a small set of optimised files. Configuration-heavy, yes — but the bundling model it established underpins the entire modern frontend.

Comments

Post a Comment

Popular posts from this blog

Swift Explained: Apple's Language for iPhone, Mac, and More

Introduction Swift is Apple's language for its platforms: iPhone, iPad, Mac, Apple Watch, and Apple TV. Introduced in 2014 to replace the older Objective-C, it was designed to be safe, fast, and — unusually for a systems language — genuinely pleasant to read and write. Even if you never ship an app, Swift teaches one idea every developer should understand: optionals. Optionals: saying "this might be missing" Most bugs in app development come from one cause: code assuming a value exists when it does not. Swift makes that assumption impossible to hide. A value that might be missing is wrapped in an Optional, and you must unwrap it before use. var nickname: String? = nil nickname = "Waqas" if let name = nickname { print("Hello, \(name)!") } else { print("No nickname set.") } String? means "a String, or nothing". The if let unwraps it safely: inside the block, name is guaranteed to exist. There is no way to accidentally us...
Read more

Flutter Explained: One Codebase, Every Screen

Introduction Flutter is Google's framework for building apps from a single codebase: write once in Dart, and ship to iOS, Android, web, Windows, macOS, and Linux. It powers apps from Google Pay to the New York Times crossword app. Its core idea is simple and radical: everything on screen is a widget, and the interface is rebuilt from data whenever that data changes. Everything is a widget In Flutter, there are no separate concepts for layout, styling, and controls — everything is a widget, nested inside other widgets like HTML elements, but in code: import 'package:flutter/material.dart'; class Greeting extends StatelessWidget { @override Widget build(BuildContext context) { return Center( child: Text( 'Hello, Sara!', style: TextStyle(fontSize: 24, color: Colors.teal), ), ); } } Center positions its child, Text displays words, TextStyle styles them — each a widget, composed by nesting. Layout widgets (like Row, Column, ...
Read more

Go Explained: Simple Code That Runs Fast

Introduction Go was built at Google for a specific frustration: large programs that were slow to build and hard to read. The answer was a language that is deliberately small — fewer features, but the right ones, done well. If you know one programming language already, Go will feel familiar within an hour. The interesting parts are not the syntax, but two ideas: goroutines and channels. Goroutines: cheap concurrency Most languages make running things at the same time feel heavy — threads, thread pools, and careful setup. A goroutine is Go's lightweight version: you start one by writing go in front of a function call. package main import ( "fmt" "time" ) func say(text string) { for i := 0; i < 3; i++ { fmt.Println(text) time.Sleep(100 * time.Millisecond) } } func main() { go say("hello") say("world") time.Sleep(500 * time.Millisecond) } The go say("hello") line does not wait — it st...
Read more