How Webpack Evolved: From Simple Bundler to Full‑Featured Frontend Build Tool

Introduction

Modular programming is a key idea in software design. In JavaScript, handling modules has always been a challenge because browsers can only execute JavaScript, CSS, and HTML. Therefore, front‑end modular code must be transformed before it can run. CommonJS, AMD, and the ES6 module specification are examples of module systems that browsers cannot directly execute, so dedicated tools are required to convert source code into browser‑compatible bundles.

The transformation process is called a build, where module bundlers or loaders play a central role.

Webpack is a JavaScript module bundler. Before Webpack, developers used tools such as Browserify to compile and bundle CommonJS modules, or Gulp to orchestrate a series of tasks for front‑end automation. Those approaches kept compilation, packaging, and resource handling separate.

Webpack’s module system can manage all application resources—JavaScript, CSS, HTML, images, etc.—as modules, bundle them into one or more optimized files, and handle complex dependency graphs. Its power and flexibility have made it the de‑facto choice for modern front‑end builds.

This article explores Webpack’s development history, showing how it grew from a simple bundling tool into a comprehensive front‑end build ecosystem.

Webpack Development Timeline

From its first major release in September 2012 to October 2020, Webpack has produced five major versions. The diagram below (originally in Chinese) illustrates the key changes of each version.

Direction of Version Changes

Webpack 1 : Replaced Gulp‑based task orchestration. Its initial release offered a new way to bundle resources, emphasizing a unified module system.

Concept : Everything is a resource—HTML, JS, CSS, images, text, JSON—handled modularly.

Core : Introduced a unique module loading mechanism and the concepts of module bundling and code splitting.

Features : Combined compilation, packaging, optimization, and performance improvements into a single tool.

Characteristics : Configuration‑driven builds with extensible

loader

and

plugin

APIs.

Webpack 2 : Arrived four years after version 1, adding native ES6 module support, the import syntax for on‑demand loading, and Tree Shaking for dead‑code elimination.

Webpack 3 : Focused on build speed and bundle size optimizations, introducing Scope Hoisting and the module.noParse option.

Webpack 4 : Delivered significant performance gains, emphasized out‑of‑the‑box experience, and added the mode option (development vs. production) and built‑in Web Worker support.

Webpack 5 : Further improved build performance and output, introduced WebAssembly module support, persistent file‑system caching, and Module Federation for sharing modules across applications.

Analyzing Webpack‑Generated Code

To understand the following sections, we first look at a low‑version Webpack bundle (simplified for illustration).

<code>(function(modules) {
    // webpackBootstrap
    // The module cache
    var installedModules = {};
    // The require function
    function __webpack_require__(moduleId) {
        // ...
    }
    // expose the modules object (__webpack_modules__)
    __webpack_require__.m = modules;
    // expose the module cache
    __webpack_require__.c = installedModules;
    // __webpack_public_path__
    __webpack_require__.p = "";
    // Load entry module and return exports
    return __webpack_require__(0);
})([/* 0 */ function(module, __webpack_exports__, __webpack_require__) { /* ... */ }, /* 1 */ function(module, __webpack_exports__, __webpack_require__) { /* ... */ }, /* 2 */ function(module, __webpack_exports__, __webpack_require__) { /* ... */ }]);
</code>

The entry point is an IIFE (Immediately Invoked Function Expression). Inside the IIFE, two core parts exist:

Module System : Implements

Module

,

Require

, and

Export

methods. Each module is wrapped in a function, creating a closure that isolates its scope.

Module Closure : The IIFE receives an array called

Modules

. Each array element is a module with its own scope, and modules reference each other through Webpack’s internal module system.

Who Survives and Who Disappears in Webpack’s History

Survivor: OccurrenceOrderPlugin

In Webpack 1 the plugin was named

OccurenceOrderPlugin

, renamed to

OccurrenceOrderPlugin

in Webpack 2, and became default in Webpack 3.

Purpose : Optimizes module order to reduce output size by assigning shorter IDs to frequently used modules, improving caching efficiency.

The plugin works by analyzing module usage frequency and assigning IDs based on that frequency.

Usage Frequency : Counts how many times a module is referenced by other modules; higher counts imply higher importance.

Module ID : Assigns shorter numeric IDs to the most frequently used modules, shrinking the final bundle.

Survivor: Scope Hoisting

Earlier bundles wrapped each module in its own closure, which added runtime overhead. Tools like Closure Compiler and Rollup could “hoist” modules into a single closure. Scope Hoisting performs this statically, merging modules into one function scope, reducing function‑call overhead, decreasing bundle size, and improving execution speed. It is enabled by default in Webpack 5 and can be activated in Webpack 4 via the

moduleConcatenation

plugin.

CommonsChunkPlugin vs. optimization.splitChunks

CommonsChunkPlugin extracted shared modules into a separate chunk, but it was limited to entry‑chunk relationships and required complex configuration. Since Webpack 4,

optimization.splitChunks

automatically splits chunks based on configurable strategies, offering greater flexibility and simplicity. Consequently, CommonsChunkPlugin was removed.

Removed: DedupePlugin

DedupePlugin (Webpack 1) removed duplicate modules during bundling. With the introduction of Tree Shaking in Webpack 2 and Scope Hoisting in Webpack 3, deduplication became unnecessary, and the plugin was removed.

Summary

Webpack’s evolution has focused on three main goals:

Performance Optimization : Eliminating duplicate code, applying scope hoisting, and compressing bundles to reduce size and improve runtime speed.

Build Efficiency : Incremental compilation, caching, and parallel processing to accelerate builds.

Configuration Simplification : Providing sensible defaults, built‑in plugins, and streamlined configuration for a better developer experience.

Final Note

Follow the "Goodme Front‑End Team" public account for more practical front‑end insights and community sharing.