Vite & Webpack.

Vite starts fast because it does not bundle your app before serving it. A bundler such as webpack builds the whole application first, so the larger the app, the longer the wait.

Vite splits the work in two:

• Dependencies from node_modules rarely change. Vite pre-bundles them once with Rolldown, a fast bundler written in Rust. Each package becomes a single module, cached until the lockfile changes.
• Source code is served as native ES modules. The browser requests each file through import statements, and Vite compiles a file only when the browser asks for it.

So the dev server starts almost instantly, even for large applications. Hot Module Replacement (HMR) stays fast for the same reason: an edit updates just that module, with no rebuild. The trade-off is request count, since a very large codebase can load pages slowly in development.

Hot Module Replacement (HMR) swaps an edited module into the running page without a full page refresh, so application state survives the edit.

Vite's dev server detects file changes on its own and pushes each update to the browser over a WebSocket. The browser re-imports the changed module, plus any importers up to the nearest module that accepts the update. Because Vite serves native ES modules, an edit needs no bundle rebuild, so updates are nearly instant and much faster than with traditional bundlers.

Vue, React and Svelte hook into this through Vite's HMR API, import.meta.hot, to keep state across updates.

Run npm create vite@latest and answer the prompts for a project name, a framework and a variant. The command runs create-vite, a tool that scaffolds a starter project from a template. Yarn and pnpm have the same command:

# Using npm
npm create vite@latest my-project

# Using yarn
yarn create vite my-project

# Using pnpm
pnpm create vite my-project

Vite provides templates for these frameworks:

• vanilla, vanilla-ts
• vue, vue-ts
• react, react-ts, react-compiler, react-compiler-ts
• preact, preact-ts
• lit, lit-ts
• svelte, svelte-ts
• solid, solid-ts
• qwik, qwik-ts

To skip the prompts, name the template directly. With npm 7 and later, an extra -- goes before the options:

npm create vite@latest my-react-app -- --template react-ts

Then run npm install and npm run dev inside the new folder. Current Vite needs Node.js 20.19 or later, or 22.12 or later.

A Vite project keeps index.html in the project root, the source code in src, and static files in public. The Vite configuration, vite.config.js, sits in the root next to package.json.

my-vite-app/
├── public/              # Static assets served directly
│   └── favicon.ico
├── src/                 # Source code
│   ├── assets/         # Assets processed by Vite
│   ├── components/     # Components
│   ├── main.js        # Application entry point
│   └── style.css      # Styles
├── index.html         # HTML entry point (in root!)
├── package.json
└── vite.config.js     # Vite configuration

Two things differ from other bundlers. index.html lives in the root, not in a public folder, because it is the entry point Vite serves. And Vite processes the source files in src, while it serves the files in public directly and copies them to the build output unchanged.

Vite copies files in public to the build untouched, but it runs files in src/assets through its build pipeline when your code imports them.

• public: Vite serves these files at the root path, so you reference them with absolute paths such as /favicon.ico. Vite does not process them, and they keep their original names in production. Use it for favicons, robots.txt and manifest files.
• src/assets: you import these files in JavaScript or CSS. Each gets a hashed file name, plugins can process it, and only the files your code references reach the build. Use it for images, fonts and component CSS.

// src/assets - processed and hashed
import logo from './assets/logo.png'

// public - served directly
// Reference as '/logo.png' in HTML

Run npm run dev to start the development server and npm run build to create the production build. The scaffolded package.json maps these scripts to the vite and vite build commands, which you can also run directly with npx.

Start the development server:

npm run dev
# or
npx vite

Build for production:

npm run build
# or
npx vite build

Preview the production build locally:

npm run preview
# or
npx vite preview

The development server runs on http://localhost:5173 by default. It provides Hot Module Replacement, an error overlay and source maps, and with the React plugin, edits apply through React Fast Refresh.

The production build writes optimized, minified bundles to the dist directory. vite preview serves that folder at http://localhost:4173 so you can test it, but it is not a production server.

index.html is the entry point of a Vite application. Vite treats it as source code and part of the module graph, the map of which files import which. That is why it lives in the project root, not in a public folder.

Vite uses index.html like this:

1. It is the page the dev server starts from.
2. Its <script type="module"> tag tells Vite where your JavaScript starts.
3. Vite processes the HTML and injects the assets it needs.
4. In development, Vite serves the file directly.
5. During vite build, Vite injects the CSS links and updates the script paths.

<!DOCTYPE html>
<html>
<head>
  <title>Vite App</title>
</head>
<body>
  <div id="app"></div>
  <script type="module" src="/src/main.js"></script>
</body>
</html>

Webpack builds a dependency graph from an entry point and emits it as output bundles, with loaders and plugins shaping the work in between. It is a static module bundler, which follows every import and require from the entry and combines the modules into bundles. The four main concepts:

1. entry is the module where webpack starts building the dependency graph, ./src/index.js by default.
2. output sets where and how to emit the bundles, ./dist/main.js by default.
3. Loaders, set in module.rules, transform files from other languages and formats, such as CSS or TypeScript, into modules.
4. plugins extend webpack for wider tasks such as bundle optimization, asset management and injecting environment variables.

The docs list two more core concepts. mode turns on built-in defaults for development or production. The other is browser compatibility. The code webpack generates uses Promise for import(), so older browsers need a polyfill.

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js'
  },
  module: {
    rules: [{ test: /\.js$/, use: 'babel-loader' }]
  },
  plugins: [new HtmlWebpackPlugin()]
};

A webpack.config.js file is a Node.js module that exports one configuration object. Webpack uses it automatically when it sits in the project root, and the --config flag points to another file. Each top-level key controls one part of the build:

const path = require('path');
module.exports = {
  mode: 'development', // or 'production'
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js'
  },
  module: {
    rules: [
      // Loader configurations
    ]
  },
  plugins: [
    // Plugin instances
  ],
  devServer: {
    // Dev server configuration
  }
};

• mode turns on webpack's built-in defaults for development or production.
• entry is the module where webpack starts building the dependency graph.
• output sets the folder and file name of the bundles. The folder must be an absolute path, which is why the config calls path.resolve.
• module.rules lists the loaders that transform files such as CSS or TypeScript.
• plugins holds plugin instances that work on the whole build.
• devServer configures webpack-dev-server for local development.

The file can also export a function that receives the CLI's env and argv, so one file can return a different config per environment.

A loader transforms a file from another language or format into a module webpack can bundle. That is how an import can pull in CSS, TypeScript or modern JavaScript that older browsers cannot run.

Loaders run during the build, one file at a time. When a file matches a rule's test in module.rules, webpack runs that rule's loaders on its source. The exclude option skips paths such as node_modules.

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      },
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env']
          }
        }
      }
    ]
  }
};

Here babel-loader compiles modern JavaScript with the @babel/preset-env preset passed in its options. Loaders in a use array run right to left, or bottom to top, and each receives the previous loader's output. So css-loader reads the CSS first, then style-loader injects it into the page.

css-loader turns a CSS file into a JavaScript module, and style-loader puts that CSS on the page. In the classic setup, the two work together so that import './styles.css' styles the page.

• css-loader interprets @import and url() the way webpack treats import and require(). It resolves those CSS dependencies and returns the CSS as a string.
• style-loader injects that CSS into the DOM by adding <style> tags when the bundle runs.

Loaders run right to left, so style-loader sits first in the array and runs after css-loader.

// This processes CSS files and injects them into the DOM
{
  test: /\.css$/,
  use: ['style-loader', 'css-loader']
}

For production, MiniCssExtractPlugin.loader has long replaced style-loader, so the CSS goes into separate .css files the browser can cache. Since webpack 5.109, built-in CSS support is on by default for .css files that no loader rule matches. It can extract or inject styles itself, and mini-css-extract-plugin is now deprecated.

A webpack plugin works on the whole compilation, while a loader transforms one file at a time.

Loaders work at the file level. They process each matching file before its module is added to the bundle. Plugins work at the bundle level. They hook into the build process, so they can change it, add files to the output or optimize the result.

const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html'
    })
  ]
};

You add a plugin by creating an instance with new in the plugins array. Here HtmlWebpackPlugin builds an HTML file from a template and adds the bundles to it.

HtmlWebpackPlugin generates the HTML file that loads your webpack bundles, so you never maintain the <script> and <link> tags by hand.

• It adds a tag for every bundle automatically.
• When file names carry a content hash for cache busting, the plugin writes the new names on every build.
• It can start from your own HTML template with variables.
• One plugin instance per page builds a multi-page app.

new HtmlWebpackPlugin({
  template: './src/index.html',
  filename: 'index.html',
  chunks: ['app'], // Only include specific chunks
  minify: process.env.NODE_ENV === 'production'
})

Here chunks limits the page to the app bundle, and minify turns HTML minification on for production builds.

You configure webpack-dev-server in the devServer key of webpack.config.js and start it with npx webpack serve. It serves your app during development and rebuilds as you save.

module.exports = {
  devServer: {
    static: './dist',
    port: 3000,
    open: true,
    hot: true,
    compress: true,
    historyApiFallback: true, // For SPA routing
    proxy: [
      {
        context: ['/api'],
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    ]
  }
};

• static serves files from a folder, public by default.
• hot turns on Hot Module Replacement, which is already the default.
• compress enables gzip.
• open opens the browser after the server starts.
• historyApiFallback serves index.html in place of 404 responses, which client-side routing needs.
• proxy forwards API requests such as /api to another server. Since webpack-dev-server 5, it takes an array of objects with a context list.

changeOrigin rewrites the Host header to match the target, because the original header is kept by default.

Transpilation changes the syntax, minification makes the code smaller without changing what it does, and compression encodes the bytes sent over the network.

Transpilation is about compatibility, such as erasing TypeScript types or rewriting modern syntax for older browsers. Minification is about size, and most of its savings come from removing whitespace and shortening names, called mangling. Compression comes last. The server sends the minified file gzip or Brotli encoded, and the browser decodes it to the same text. Some builds also write pre-compressed .gz or .br files so the server does not compress on every request.