Vite: How to fail on killing Webpack

Or better yet, this is why you’re still using Webpack

Photo by Josh Marshall on Unsplash

In the never ending battle for bundlers, Vite comes from the hands of Evan You, the one who created Vue. Considering the exponential success that Vue has gained thanks for its simplicity and flexibility, the same was expected of Vite 2.0.

Vite comes as a replacement of Webpack. It aims to be like Webpack to compile your Javascript and CSS assets, but targeting modern browsers instead of piling up legacy code, which in turn promises better performance and development experience than other bundlers.

So how its like working with Vite? Performance is on track, I’m not gonna lie about that, but developer experience is far worse for everybody except those who are 100% into Javascript.

This is probably one of these packages that raises from obscurity to rockstar level in some months, then tanks and get slowly replaced by another tool, like the one that’s been forever and actually works for every user case, called Webpack.

One directory to rule them… one

One of the thing that Vite assumes is the development directory. It thinks that you will use a single HTML page for an Single Page Application, and that all your assets are under a source folder inside that root directory.

project/
├─ node_modules/
├─ public/
├─ css/
│  └─ app.css
├─ js/
│  └─ app.js
├─ .gitignore
├─ index.html
└─ README.md

Modern convention uses a separate public folder where the site resides, while the source is separated from these since are not public to start.

project/
├─ node_modules/
├─ public/
│  └─ index.html
├─ src/
│  ├─ css/
│  │   └─ app.css
│  └─ js/
│      └─ app.js
├─ .gitignore
└─ README.md

You will be baffled to know that Vite doesn’t allows to separate both types of code, and the configuration is very inflexible to separate these directories.

At least, you can always destroy the source files on your development machine with a cool rm -R src/.

Using a backend is painful

If you’re developing a web application with a real backend, like under React, Symfony, Laravel, or even .NET Core, you are into a world of pain.

Not only you can’t use HMR without serving the files at the same time, but dealing with the assets handled by Vite is borderline stupid. To make use of the Vite server with HMR, you’re bound to ugly hacks like linking the local server.

<script type="module" src="http://localhost:3000/@vite/client"></script>
<script type="module" src="http://localhost:3000/main.js"></script>

On production, it’s far worse, but at least you can have a manifest file to cache busting.

No configuration either

You may think that the configuration may have some kind of solution to the problems above, but not. The config is relatively simple, but doesn’t change anything from the big drawbacks from above.

import { defineConfig } from 'vite'

export default defineConfig({
    root: "src",
    publicDir: "../public",
    build: {
        outDir: "../dist"
    }
})

Vite seems like a good tool to use on small apps, personal projects 100% on Javascript, or CSS prototyping — like using Bootstrap 5 or Tailwind CSS. There is where Vite can thrive as long the project denies the backend existence at all.

On your job, however, you’re back to Webpack to do the real work until the next “Webpack-killer” comes around without dropping the dagger midair.