Understanding Frontend Bundling, Module Systems, and the Rise of Bundle‑less Development

Why Bundling Is Needed

In the era of HTTP/1.x a single TCP connection could handle only one request‑response pair, forcing browsers to open multiple connections per domain and limiting parallelism to about 6‑8 connections. Before Node.js, JavaScript ran only inside <script> tags, so large applications required many separate script files, increasing request count and making dependency order hard to maintain.

Early pages used CDN links to libraries such as jQuery and Bootstrap, and the loading order mattered because Bootstrap depends on jQuery.

Module Systems

To avoid the problems of manually concatenating scripts, several module specifications emerged:

CommonJS (cjs) : Synchronous, value‑copy exports, used by Node.js and not directly runnable in browsers.

AMD : Asynchronous loading via requirejs , works both in browsers and on the server.

CMD : Similar to AMD but relies on sea.js and only supports browsers.

ESM : Native ECMAScript modules supported by modern browsers and Node.js; supports tree‑shaking and can export references.

const axios = require("axios");

var requirejs = require('requirejs');
requirejs.config({
    paths: { lib1: 'module/index1', lib2: 'module/index2' }
});
require(["lib1","lib2"], function(l1,l2){
  l1.doSomething();
  l2.doSomething();
});

<script src="https://cdn.bootcdn.net/ajax/libs/seajs/3.0.3/sea.js"></script>
<script>
  seajs.config({ base: './module/', alias: { libAMD: 'index.js' } });
  seajs.use('./main.js');
</script>

import { value, getValue, Obj, name } from "./module/index.js";

Environment Compatibility

Although modern browsers now support ESM, older browsers still require polyfills. Moreover, many small module files increase HTTP requests, hurting performance under HTTP/1.x. Besides JavaScript, HTML and CSS also need modular handling.

Additional Work During Bundling

Bundlers often run plugins (e.g., Babel) to transpile code, perform minification, and convert languages such as TypeScript, SCSS, or Less to JavaScript and CSS.

Webpack vs. Rollup

For business platforms that must support legacy browsers, Webpack is preferred because of its rich plugin ecosystem and built‑in polyfills. For SDKs or libraries where a clean output is desired, Rollup is better as it relies on native ESM support and produces smaller bundles with better tree‑shaking.

Why Split Bundles

Large monolithic bundles increase initial load time. Splitting separates frequently changed business code from rarely changed third‑party libraries, allowing better caching. Tools like webpack-bundle-analyzer help visualize and configure split‑chunks.

Why Not Bundle (Bundle‑less Development)

Traditional bundling requires a full rebuild on every change, slowing down development. Bundle‑less tools such as Vite leverage native ESM: the browser requests each module directly, while the dev server intercepts and transforms files on‑the‑fly (e.g., JSX, TypeScript). This results in near‑instant hot‑module replacement.

Vite still pre‑bundles large third‑party dependencies (e.g., lodash) to avoid hundreds of HTTP requests, so it is not a completely “no‑bundle” approach.

Why Not Use Bundle‑less in Production

Even though browsers support ESM, the overhead of many network round‑trips and missing polyfills can degrade performance. Production builds should still perform tree‑shaking, lazy loading, and chunk splitting for optimal caching.

Summary

Bundling was originally required because of HTTP/1.x connection limits, lack of native module support, and complex dependency management. Splitting further improves caching by separating stable third‑party code from volatile business code. Modern HTTP/2, widespread ESM support, and tools like Vite enable bundle‑less development, but production still benefits from a final bundled, optimized build.