Bundling concept

Why bundle

Browsers load pages fastest with few files, but developers think best in many small modules. Bundling resolves that tension by merging the module graph into a small set of output files.

The bundler follows imports from the entry, drops unused branches where possible, and emits plain JavaScript the browser can run without knowing about the original file layout.

One entry file

Every bundle starts from one entry file that describes the whole app. The entry imports screens, helpers, and styles by name, so the full dependency tree is explicit and traceable.

Keep the entry thin: import and start, nothing more. Feature logic belongs in nearby modules where it is easy to find and test in isolation.

import { startApp } from "./app"; import { routes } from "./routes"; startApp(routes);

Split vendor sketch

App code changes daily while third party code changes rarely. Conceptually you can emit two outputs: one for your screens and one for stable vendor helpers shared across pages.

The browser then caches the vendor file longer and downloads only the changed app file. No tool setup is needed to grasp the idea, only the habit of separating own code from outside code.

// app chunk: screens that change often import { renderHome } from "./home"; // vendor chunk: stable helpers reused everywhere import { formatDate } from "./format"; renderHome(formatDate("2026-10-06"));

Measure output

A bundle is a budget, not just a build artifact. Check the emitted file names and byte sizes after each change, then ask whether a new import earned its weight.

Large jumps usually point at an accidental heavy import. Smaller focused modules keep downloads fast and make future splits almost trivial.

ls -lh dist

app.js 48K, vendor.js 122K

Next: SPA concepts

Article author: Arthur Isaev