Run a mock round

Hot Module Replacement updates modules in a running app without a full page reload, preserving application state and often scroll position. When a file changes, the dev server sends the updated module over a WebSocket. The runtime accepts the new version and re-executes it, or asks the framework to re-render the affected component.

Frameworks implement an HMR boundary: React Fast Refresh re-mounts the component while keeping state where possible, and Vue and Svelte do something similar at component level. If no boundary accepts the update, the tool falls back to a full reload.

HMR requires a dev server such as Vite or webpack-dev-server and works best with components that have clear module boundaries. Editing a module-level side effect or an exported constant often forces a reload. It is a development-only feature stripped from production, and it pairs with fast incremental builds to give quick feedback without losing the state you were testing.

CommonJS is Node's original system: require() is a function executed at runtime, module.exports is a mutable object, resolution can be dynamic and conditional, and modules are evaluated synchronously on first require, then cached.

ES modules use static import and export syntax declared at the top level. They are parsed before execution, hoisted, provide live bindings so an imported value reflects later changes, and support top-level await. Because imports are static, bundlers can tree-shake and analyse dependencies; because CommonJS is dynamic, they generally cannot.

Interop caveats: importing CommonJS from ESM usually gives a default export of module.exports, and named imports work only through tooling analysis. In Node, "type": "module" makes .js files ESM, while .cjs and .mjs force a format.

Dual-publishing a library requires a build for each format with correct exports conditions, and mixing them can cause the dual package hazard where two copies of state exist.

Library builds differ from app builds: you usually bundle to ESM and CommonJS, externalise peer dependencies such as React or Vue so consumers do not get duplicates, generate type declarations, and avoid bundling polyfills. Rollup is the classic choice because its output is clean and tree-shakeable, and tools like tsup, unbuild and Vite's library mode wrap it with sensible defaults. Configure exports with conditions for import, require and types, set sideEffects: false when true, and keep entry points minimal so consumers only pull what they use.

{
  "main": "./dist/index.cjs",
  "module": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "sideEffects": false
}

For analysis, webpack-bundle-analyzer and rollup-plugin-visualizer show a treemap of module sizes. Common findings are a library imported wholesale, duplicated versions, all moment locales, or lodash pulling everything. Fix with per-function imports, aliasing to lighter alternatives, manualChunks for vendors, and checking duplicates with npm ls. Always measure gzipped or brotli sizes, not raw bytes.

Webpack bundles everything up front: it builds the whole dependency graph, then serves from memory, so cold starts grow with project size. It is extremely configurable through loaders and plugins, supports virtually every asset type, and has a mature ecosystem plus Module Federation.

Vite takes another approach. In development it serves your source over native ESM and transforms files on demand, so the server starts almost instantly regardless of app size. Dependencies are pre-bundled once with esbuild. For production it uses Rollup, and increasingly Rolldown, to produce an optimised tree-shaken bundle, so dev and prod differ internally.

Vite has sensible defaults, built-in CSS and asset handling, fast HMR and a simpler config, but a smaller plugin surface than webpack and occasional dev-versus-build differences.

Choose Vite for most new apps for speed and simplicity. Choose webpack when you need a specific loader, Module Federation or deep legacy compatibility.

Browsers can load ES modules, but a large app would issue hundreds of requests, and TypeScript, JSX, CSS and assets all need processing. A bundler takes an entry point, follows imports to build a dependency graph, transforms each module, and emits a small number of optimised files.

It handles transpilation through loaders or plugins, resolves bare imports from node_modules, inlines or copies assets, splits the output into chunks, minifies it, and generates cache-busting hashes. It also powers development with a local server and hot module replacement.

The goal is fewer requests, smaller payloads, compatibility with older browsers and a reproducible pipeline from source to deployable assets. Modern bundlers such as Vite, esbuild and SWC reduce the cost, but the core reasons stay the same: dependency resolution, transformation and output optimisation. Without a bundler you would manage script order and duplicate dependencies by hand.

Code splitting divides the bundle so the browser downloads only what a route or interaction needs. Bundlers detect dynamic import() and create a separate chunk for that module and its exclusive dependencies. Shared dependencies may be hoisted into a common chunk to avoid duplication.

button.addEventListener('click', async () => {
  const { renderChart } = await import('./chart.js');
  renderChart();
});

Route-based splitting is the highest-value pattern, because initial load only pays for the current page. Vendor splitting separates rarely changing libraries into their own chunk so browser caching survives app updates, and framework configs often expose manualChunks or similar.

The trade-offs are more requests, duplicated code risk and a flash while a chunk loads. Mitigate with preload or prefetch, such as link rel="modulepreload" and router prefetching, plus loading states. Set hashed chunk file names for long-term caching, measure with a bundle analyser, and avoid splitting so finely that request overhead dominates.

Babel is a JavaScript compiler that transforms modern syntax into code older environments can run. It parses source into an AST, applies plugins that each handle a transformation such as arrow functions, optional chaining, class fields or JSX, and generates new code.

Presets bundle common plugin sets. @babel/preset-env uses your browserslist or targets to include only the transforms needed, while @babel/preset-react and @babel/preset-typescript handle JSX and TypeScript syntax. It can add polyfills through core-js with useBuiltIns: 'usage', though Babel does not polyfill language features automatically without that.

{ "presets": [["@babel/preset-env", { "targets": ">0.5%, not dead" }]] }

Babel operates file by file and is relatively slow, so modern toolchains often replace it for transpilation. It does not bundle; that is the bundler's job. Babel remains valuable for custom transforms, macros and precise browser targeting.