Tags: web-dev concept

Vite

Date: 2026-08-17

---

A build tool that skips bundling during development and bundles for production. The asymmetry is the whole idea — dev server startup becomes independent of project size, which is the thing that made every previous bundler painful on a large codebase.

---

Vite is a front-end build tool with two distinct modes: a development server serving native ES modules, and a production build using a bundler.

§0 The one idea

Browsers support ES modules natively, so during development you don’t need to bundle at all.

TRADITIONAL BUNDLER, DEV
  bundle the ENTIRE app
    ↓ then serve
  startup time grows with project size
  a change re-bundles a chunk of it

VITE, DEV
  serve index.html
    ↓ browser requests modules
  transform each file ON DEMAND
  startup is near-instant, whatever
  the project size

Cold start stops scaling with the codebase. That’s the practical difference people notice immediately on a large project — Build Tools.

Dependencies versus source

Vite treats the two completely differently, and this is where the speed comes from:

	Dependencies	Your source
Change	Rarely	Constantly
Handled by	Pre-bundled once	Transformed on demand
Why	Many packages ship CommonJS that must be converted, and it’s stable	Needs to reflect edits instantly

Pre-bundling dependencies also collapses request count. A package split across 200 internal modules would otherwise be 200 requests; pre-bundled it’s one.

Hot module replacement

you save Button.tsx
  ↓
Vite invalidates ONLY that module
  ↓
the browser swaps it in place
  ↓
application state is preserved

HMR time is proportional to the changed module, not the application. This is the second thing people notice, and it’s why the feedback loop stays fast as a project grows.

The bundler, and the dual-tool problem it solved

Historically Vite used two different bundlers — esbuild for development transforms and dependency pre-bundling, Rollup for the production build. Fast, and it meant dev and production didn’t run identical code paths, so a bug appearing only in the production build was possible. That was the standard criticism.

Vite 8, released March 2026, replaced both with Rolldown — a Rust bundler, written as a drop-in Rollup replacement, now used for development and production alike.

BEFORE (Vite ≤7)     esbuild for dev
                     Rollup for production
                     → two code paths

FROM Vite 8          Rolldown for both
                     → one code path

What the unification buys, beyond consistency: substantially faster production builds, plus capabilities the split made awkward — module-level persistent caching, more flexible chunk splitting, and full-bundle mode.

[CHECK: which Vite major you’re on before assuming either architecture — the dual-bundler model applies to 7 and earlier, and plenty of projects haven’t upgraded.]

The practical advice is unchanged regardless: run the production build in CI on every pull request rather than only at release, and have a preview environment — Preview Environments.

Configuration

Vite works with no config for a plain project. The settings actually worth setting:

// vite.config.js
import { defineConfig } from 'vite'
 
export default defineConfig({
  build: {
    target: 'es2020',
    sourcemap: 'hidden',
    rollupOptions: {
      output: { manualChunks: { vendor: ['react'] } },
    },
  },
  server: { proxy: { '/api': 'http://localhost:3000' } },
})

• target — how much gets transpiled, and the biggest lever on output size — Transpilation
• sourcemap: 'hidden' — generate maps without referencing them in the shipped file — Source Maps
• manualChunks — override automatic splitting where you know better — Code Splitting
• server.proxy — avoid CORS in development without changing your API

Environment variables

VITE_API_URL=https://api.example.com   → exposed
DATABASE_URL=postgres://...            → not

Only variables prefixed VITE_ are exposed to client code. That prefix is a safety mechanism, and it means anything so prefixed is public — minification is not obfuscation — Secrets Management.

Where it fits

USE IT FOR
  single-page applications
  component libraries
  anything previously on webpack
  as the build under a framework
  (SvelteKit, Nuxt, Astro use it)

CONSIDER OTHERWISE
  a framework with its own build
  (Next.js) — use theirs
  a server-rendered app where the
  PLATFORM owns the asset pipeline
  (a classic Shopify Liquid theme)
  — Shopify

See: Shopify

Note which stacks this does not exclude. A server-rendered application can still have a conventional front-end build — AEM’s ui.frontend is an ordinary npm project compiling into a clientlib, and Vite would serve it perfectly well. The question is whether the platform owns the asset pipeline, not whether rendering happens on the server — Reference - AEM.

Vite has become the default for the non-framework case, and its dependency pre-bundling model has been widely adopted — which is a fair sign the core insight held.