Why We Chose Vite 7 Over Everything

We evaluated every serious JavaScript bundler in January 2026. The evaluation was not theoretical. We ported our production build — 47 routes, 34 blog posts via content-collections, Tailwind CSS v4, TanStack Router with code splitting — to each bundler and measured cold build time, HMR latency, and production bundle size. The results were not close.

Vite 7 with the Rolldown backend won on every metric that matters. This is not an opinion. It is a measurement.

The State of JS Bundlers in 2026

The bundler landscape has collapsed into three viable options. Everything else is either dead, dying, or niche enough to disqualify itself for production use.

Webpack is dead. Not deprecated — dead. Webpack 5 still works. Its plugin ecosystem is enormous. But cold build times for a project of our size are 14.2 seconds, HMR takes 600-900ms for a component change, and the configuration complexity is unjustifiable in 2026. Every hour an engineer spends debugging a Webpack configuration is an hour not spent on work that generates revenue. We ran Webpack for two years. We do not miss it.

Turbopack is not ready. Vercel has been promising Turbopack as the Webpack successor since October 2022. It is now March 2026. Turbopack works inside Next.js for development. It does not work as a standalone bundler. It does not have a stable plugin API. It does not support the Rollup plugin ecosystem. The dev server is fast — we measured 38ms HMR on component changes — but being locked into Next.js for that performance is not a trade we will make. We do not use Next.js. We use TanStack Start. Turbopack has no path to supporting our stack.

Vite 7 is the correct answer. Here is why.

The Rolldown Integration

Vite 7's defining change is the Rolldown backend. Previous Vite versions used esbuild for development transforms and Rollup for production builds. This dual-bundler architecture created a category of bugs where code worked in development but broke in production because esbuild and Rollup handle edge cases differently. We hit this twice in 2025 with CSS module ordering and dynamic import expressions.

Rolldown replaces both. It is a Rust-based bundler that implements the Rollup API with 10-30x better performance. Vite 7 uses Rolldown for both development and production, eliminating the dev/prod behavior mismatch entirely.

The Rolldown migration was transparent to us. We changed nothing in our Vite configuration. Our Rollup-compatible plugins continued to work. The build got faster. That is the ideal migration: zero effort, measurable improvement.

Our Vite Configuration

Our vite.config.ts composes four plugins:

import { defineConfig } from "vite";
import { tanstackStart } from "@tanstack/vite-plugin";
import { contentCollections } from "@content-collections/vite";
import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
  plugins: [
    tanstackStart(),
    contentCollections(),
    tailwindcss(),
  ],
});

That is the entire configuration. No loaders. No rules. No resolve aliases (TanStack Start handles path aliases via tsconfig). No manual chunk splitting (Rolldown's automatic chunking produces better results than our hand-tuned manual chunks did with Webpack). No CSS extraction configuration (Tailwind v4's Vite plugin handles this automatically).

The three plugins compose without conflicts because they operate on different phases of the build pipeline:

1. TanStack Start plugin handles route discovery, server function transforms, and SSR configuration. It runs first and sets up the entry points.
2. content-collections plugin runs during the transform phase, compiling Markdown content and generating typed exports. It does not interfere with route discovery because it operates on .md files, not route files.
3. Tailwind v4 plugin runs as a CSS transform, processing @tailwind directives and utility classes. It operates exclusively on CSS and does not touch JavaScript transforms.

This composability is not accidental. Vite's plugin API is ordered and phased. Plugins declare which hooks they use (resolveId, load, transform, renderChunk), and Vite orchestrates them in a predictable sequence. We have never had a plugin ordering conflict. With Webpack, we had a plugin ordering conflict approximately once per quarter.

Build Performance

Cold production build, measured on an M3 MacBook Pro (12-core, 36GB RAM):

| Bundler | Cold Build | Hot Rebuild | Output Size | |---------|-----------|-------------|-------------| | Vite 7 (Rolldown) | 1.8s | 0.3s | 412KB | | Vite 6 (esbuild + Rollup) | 3.4s | 0.7s | 428KB | | Webpack 5 | 14.2s | 2.1s | 461KB | | esbuild (standalone) | 0.9s | 0.2s | 487KB |

esbuild is faster in raw build speed but produces larger bundles because it does not perform the same scope hoisting and tree-shaking optimizations that Rolldown inherits from Rollup's architecture. The 75KB difference in output size matters: on our user base (predominantly Southeast Asian mobile users on variable-quality connections), 75KB is 200-400ms of additional load time on a 3G connection.

Vite 7 hits the optimal point in the build-speed-versus-output-size tradeoff. A 1.8-second build means our CI/CD pipeline from push to production deploy is under 45 seconds total. That feedback loop changes how we work. Engineers push small changes frequently because the cost of a deploy is negligible. We deploy to production 15-20 times per day.

HMR Performance

Hot Module Replacement is where Vite's architecture pays its largest dividend. Our measurements for a typical component change (modifying a React component that renders ad creative previews):

• Vite 7: 34ms from save to screen update
• Vite 6: 48ms
• Webpack 5: 740ms
• Turbopack (Next.js): 38ms

34ms is below the threshold of human perception. When an engineer modifies a component and saves, the change appears on screen before their eyes move from the editor to the browser. This is not a luxury. We build ad creatives that run across thousands of format variations. Our designers and engineers iterate on creative layouts dozens of times per hour. The difference between 34ms and 740ms HMR is the difference between a fluid creative workflow and one interrupted by constant waiting.

Vite achieves this through its unbundled development architecture. In development mode, Vite does not bundle your application. It serves ES modules directly to the browser, transforming files on demand. When a file changes, Vite only re-transforms that single file and sends it to the browser via WebSocket. The browser's native ES module system handles the rest.

Rolldown's integration in Vite 7 makes this even faster because the transform step (TypeScript stripping, JSX compilation, CSS modules) is now handled by Rust instead of esbuild's Go. The 14ms improvement over Vite 6 comes entirely from faster transforms on the changed file.

The Plugin Ecosystem

Vite's strongest competitive moat is not its build speed. It is the Rollup-compatible plugin API.

Rollup has been the dominant library bundler for years. Its plugin ecosystem covers every conceivable use case: image optimization, SVG components, WASM loading, GraphQL transforms, MDX compilation, environment variable injection, bundle analysis, and hundreds more. Vite inherits all of this. When we need a new build capability, we search for a Rollup plugin. There is always one. It works with Vite without modification.

Turbopack cannot make this claim. Its plugin API is proprietary and incomplete. esbuild's plugin API is deliberately limited — its author has stated that complex transforms should happen outside the bundler. Webpack's plugin ecosystem is large but Webpack-specific; those plugins do not work anywhere else.

The Rollup plugin API is an industry standard. Libraries publish Rollup/Vite plugins as first-party integrations: TanStack, content-collections, Tailwind, Sentry, Vitest. This network effect compounds over time. Every new library that ships a Vite plugin makes Vite harder to leave and every alternative harder to adopt.

We have no plans to leave.

Configuration as a Liability

We want to say something that will be unpopular with the "configure everything" crowd: build tool configuration is a liability. Every line in your bundler configuration is a line that can break, a line that must be maintained, and a line that a new engineer must understand before they can be productive.

Our Webpack configuration in 2024 was 340 lines. Our Vite configuration is 12 lines. That is not because Vite is less capable. It is because Vite's defaults are correct for modern web development and its plugin API allows functionality to be composed in isolation rather than configured in a monolithic file.

When a new engineer joins Anokuro, they run bun install and bun dev. The dev server starts in 400ms. They make a change. It appears in 34ms. They have never seen our build configuration because they do not need to. The build tool is invisible. That is what good infrastructure looks like.

Vite 7 with Rolldown is the correct bundler for 2026. It is the fastest practical option, it has the strongest plugin ecosystem, and it requires the least configuration. We are done evaluating bundlers.