For years, Webpack was the default answer to “how do I bundle my JavaScript?”. In 2026 that has changed. Most new projects start with Vite. Webpack, meanwhile, still runs a huge share of existing apps, and WordPress’s own block tooling, @wordpress/scripts, is still built on it.
The State of JavaScript 2025 survey shows the shift clearly. Slightly more respondents have used Webpack (87%) than Vite (84%), but Vite’s satisfaction score is 98% against Webpack’s 26%. Developers still use Webpack, and most would rather be using Vite.
This guide compares Vite vs Webpack in plain terms: how each one works, what changed in 2026, side-by-side configs, how to use Vite in a WordPress theme, and when Webpack is still the better choice.
What a build tool actually does
Browsers can run modern JavaScript directly, so why build at all? Because real projects need more than the browser gives you for free:
- Bundling: combining hundreds of modules and npm packages into a few files.
- Transforming: TypeScript, JSX, Vue or Svelte files into plain JavaScript; Sass or PostCSS into CSS.
- Optimising: minifying, removing unused code (tree shaking) and splitting code into chunks that load on demand.
- Cache busting: file names with content hashes, such as
main.4f9a1c.js, so visitors never get stale files. - A dev server: a local server that reloads the page, or only the changed module, when you save.
Vite and Webpack do all of this. The difference is how, and that’s what decides how fast your project feels day to day.
How Webpack works
Webpack is a bundle-first tool. Starting from your entry file, it follows every import, runs each file through its loaders, and builds a complete bundle, in development as well as for production. Only then can the dev server show the page.
That approach is extremely flexible. Loaders and plugins can change almost anything, and features like Module Federation (sharing code between separately deployed apps) started in Webpack. The cost is speed: the bigger the project, the longer cold starts and rebuilds take, and the config grows with every feature you add.
Webpack is still actively maintained. Version 5 is the current major release (5.112 came out in October 2026), and the team’s 2026 roadmap works towards Webpack 6: native CSS without extra plugins, TypeScript without ts-loader, and a “universal” target for Node, browsers, Bun and Deno. There is no release date for Webpack 6 yet.
How Vite works
Vite splits the job in two:
- In development, it doesn’t bundle your code. It serves your source files as native ES modules, and the browser requests only the files the current page imports. Vite transforms each file on demand, so the dev server starts almost instantly, even in large projects. Hot Module Replacement (HMR) updates only the module you changed.
- For production, it bundles everything into optimised files, because shipping hundreds of separate modules to visitors would be slow.
The big change in 2026 is Vite 8, released on March 12, 2026. Earlier versions used two tools: esbuild in development and Rollup for production builds, which sometimes behaved differently. Vite 8 replaces both with Rolldown, a single Rust-based bundler, and uses Oxc to transform code. The Vite team reports production builds that are 10 to 30 times faster than Rollup in benchmarks. One real-world example from the announcement: Linear’s production build went from 46 seconds to 6.
Node.js version
Vite 8 needs Node.js 20.19+ or 22.12+, the same as Vite 7. Check yours with node -v before you start.
Vite vs Webpack at a glance
| Feature | Vite 8 | Webpack 5 |
|---|---|---|
| Dev server start | Near-instant: serves native ES modules on demand | Builds the whole bundle first; slower as the project grows |
| Production bundler | Rolldown (Rust) | Webpack's own JavaScript bundler |
| Hot reload (HMR) | Updates only the changed module; stays fast in big apps | Works well, but rebuild time grows with the bundle |
| Configuration | Works with zero config; small vite.config.js |
webpack.config.js with loaders and plugins for most features |
| TypeScript, JSX, CSS | Built in | Needs loaders (ts-loader or babel-loader, css-loader …) |
| Entry point | index.html (or JS files in library/backend mode) |
A JavaScript file |
| Plugins | Vite and Rollup-style plugins | The largest plugin and loader ecosystem |
| Module Federation | Via community plugins | Built in |
| Satisfaction (State of JS 2025) | 98% | 26% |
The same project in both tools
Here is a small app with one JavaScript entry and a CSS file, set up both ways. First Webpack. You need the bundler, its CLI and dev server, plus a loader and a plugin just to get CSS into its own file:
npm install --save-dev webpack webpack-cli webpack-dev-server css-loader mini-css-extract-plugin html-webpack-pluginconst path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
entry: './src/main.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].[contenthash].js',
clean: true,
},
module: {
rules: [
{ test: /\.css$/, use: [MiniCssExtractPlugin.loader, 'css-loader'] },
],
},
plugins: [
new MiniCssExtractPlugin({ filename: '[name].[contenthash].css' }),
new HtmlWebpackPlugin({ template: './index.html' }),
],
devServer: { hot: true, open: true },
};Now Vite. Create the project with the official starter:
npm create vite@latest my-app
cd my-app
npm install
npm run dev # dev server with HMR
npm run build # production build in dist/That’s it: no config file is needed. CSS imported in main.js is extracted, hashed and minified automatically, and TypeScript or JSX files work out of the box. Vite’s entry point is a normal index.html that loads your script as a module:
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My app</title>
</head>
<body>
<div id="app"></div>
<script type="module" src="/src/main.js"></script>
</body>
</html>Using Vite in a WordPress theme
WordPress has no index.html: PHP prints the pages and you load assets with wp_enqueue_script() and wp_enqueue_style(). Vite handles this with its manifest, a JSON file that maps each source file to its hashed output. Point Vite at your theme’s source files and turn the manifest on:
import { defineConfig } from 'vite';
export default defineConfig({
base: './', // relative URLs for fonts and images in CSS
build: {
outDir: 'dist',
manifest: true, // writes dist/.vite/manifest.json
rolldownOptions: { // "rollupOptions" before Vite 8
input: 'src/main.js',
},
},
});Then read the manifest in your theme and enqueue the hashed files. Vite outputs ES modules, so use wp_enqueue_script_module() (WordPress 6.5+), which prints type="module" for you:
function mytheme_enqueue_vite_assets() {
$manifest = get_theme_file_path( 'dist/.vite/manifest.json' );
if ( ! file_exists( $manifest ) ) {
return; // Run "npm run build" first.
}
$entries = json_decode( file_get_contents( $manifest ), true );
$entry = $entries['src/main.js'] ?? null;
if ( ! $entry ) {
return;
}
foreach ( $entry['css'] ?? array() as $i => $file ) {
wp_enqueue_style( 'mytheme-main-' . $i, get_theme_file_uri( 'dist/' . $file ), array(), null );
}
wp_enqueue_script_module( 'mytheme-main', get_theme_file_uri( 'dist/' . $entry['file'] ), array(), null );
}
add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_vite_assets' );The version argument is null because the file names already contain a content hash. Run npx vite build --watch while you work and Vite rebuilds on every save. If enqueueing is new to you, read our guide to properly enqueueing JavaScript and CSS in WordPress first.
Building Gutenberg blocks?
For custom blocks, stick with @wordpress/scripts (wp-scripts build). It still uses Webpack, and it generates the .asset.php dependency files WordPress expects. In April 2026 the WordPress team introduced @wordpress/build, an esbuild-based replacement that already builds Gutenberg itself. The plan is for it to run under wp-scripts later, so your wp-scripts build command keeps working when the switch happens.
When to choose Vite
- Any new project: a React, Vue, Svelte, Preact or plain JavaScript app, a theme or a small library.
- Slow dev servers: if you wait seconds for every reload, Vite’s on-demand dev server is the biggest win.
- Small teams: less config to write, read and maintain.
- Framework tooling: Vue, SvelteKit, Nuxt, Astro, Remix/React Router and Vitest are all built on Vite, so you’re already in its ecosystem.
When Webpack is still the right call
- A large, working Webpack app: if builds are acceptable, a migration costs time and adds risk for little gain.
- Custom loaders and plugins: Webpack-only plugins, unusual file types or a custom build pipeline that has no Vite equivalent.
- Module Federation at scale: micro-frontends that share code at runtime are still most mature in Webpack.
- WordPress blocks:
@wordpress/scripts, as explained above.
Stuck on Webpack but need speed? Look at Rspack, a Rust-based bundler that is largely compatible with Webpack’s config and plugins. It’s often the fastest way to speed up a big Webpack project without rewriting the build.
How to migrate from Webpack to Vite
- Install Vite (
npm install --save-dev vite) and the plugin for your framework, such as@vitejs/plugin-reactor@vitejs/plugin-vue. - Move
index.htmlto the project root and load your entry with<script type="module" src="/src/main.js">. Removehtml-webpack-plugin. - Replace environment variables:
process.env.API_URLbecomesimport.meta.env.VITE_API_URL. Only variables prefixed withVITE_reach the browser. - Swap loader features: CSS, CSS modules, JSON, TypeScript and assets work without loaders. Sass only needs
npm install --save-dev sass. Webpack-onlyrequire.context()becomesimport.meta.glob(). - Convert CommonJS: change
require()andmodule.exportsin your own code toimportandexport. - Update scripts in
package.jsontovite,vite buildandvite preview, then compare the new production build with the old one before you delete the Webpack config.
// Webpack
const apiUrl = process.env.API_URL;
const pages = require.context('./pages', true, /\.js$/);
// Vite
const apiUrl = import.meta.env.VITE_API_URL;
const pages = import.meta.glob('./pages/**/*.js');Upgrading from Vite 7?
Most projects upgrade without changes: Vite 8 converts old build.rollupOptions and esbuild settings to their Rolldown and Oxc equivalents automatically. Rename them to build.rolldownOptions and oxc when you can, because the old names are deprecated. For a large project, the Vite team suggests trying the rolldown-vite package on Vite 7 first.
Frequently asked questions
Is Webpack dead in 2026?
No. It’s maintained, gets regular releases and runs a large part of the web. It’s simply no longer the default for new projects.
Is Vite only for Vue?
No. Vite was created by Evan You, the author of Vue, but it’s framework-agnostic. It has official templates for vanilla JavaScript, React, Preact, Lit, Svelte, Solid and Qwik as well as Vue.
Is Vite faster than Webpack for production builds too?
Usually yes, especially since Vite 8 switched to the Rust-based Rolldown bundler. The biggest difference is still in development, where Vite doesn’t bundle at all.
Can I use Vite with jQuery or plain JavaScript?
Yes. Pick the “Vanilla” template, npm install jquery and import it like any other module. You still get minification, hashing and a fast dev server.
Conclusion
For a new project in 2026, choose Vite: a faster dev server, faster builds since Rolldown arrived, and far less configuration. Keep Webpack where it already works well, where you depend on its plugins or Module Federation, and for WordPress blocks through @wordpress/scripts. If you’re stuck with a slow Webpack build, Rspack is a quick win before a full migration.
Want help moving a theme or app to a modern build setup? Request a free quote and we’ll get back to you with a plan and a price.
Before you go
Key takeaways
- Vite serves native ES modules in development, so the dev server starts almost instantly; Webpack bundles everything first.
- Vite 8 (March 2026) builds with Rolldown, a Rust bundler reported at 10–30x faster than Rollup.
- Webpack 5 is still maintained and is still the engine behind
@wordpress/scriptsfor Gutenberg blocks. - In a WordPress theme, enable Vite's manifest and enqueue the hashed files with
wp_enqueue_script_module(). - Start new projects with Vite; migrate a working Webpack app only when build speed or config upkeep really hurts.
