The line in your proposal that says Vite, and why it isn't really a decision

A build tool, which is a different category from everything else on the list

Almost everything else in a stack list is a thing your product is made of. A framework, a database, a host. Vite isn't. It's a step in between, and its job is to turn the files a developer writes into the files a browser can actually load.

Those two sets of files aren't the same, which surprises people. A developer works in dozens or hundreds of small files, in shorthands a browser doesn't read directly. A browser wants a few finished files, as small as possible, in plain HTML, CSS and JavaScript. Something has to do the translating.

Vite does that twice over. While the work is happening it runs the local preview a developer keeps open all day. When the work ships it runs once and produces the finished files that go on your host. Then it's out of the picture. It doesn't run on your server, and it isn't part of what visitors download.

It exists because of a wait

The reason a new build tool caught on isn't glamorous. It's the gap between saving a file and seeing the change on screen.

Older tools did the same work twice over. To show a local preview they read the whole project, translated all of it and joined it into one bundle, which is what they also did to produce the finished site. Fine on a small project. On a large one, starting the preview was slow enough to be its own interruption, and a one-line change took long enough to break concentration.

Vite's move was to stop bundling during development. Browsers can load small modules directly now, so while somebody works it serves the one file the browser just asked for and translates only that. Startup stops depending on how big the project has grown.

Be clear about who that helps. It's the developer's time, not your visitor's page speed. What it buys is more attempts per day at getting something right, not a faster website.

Why it ended up underneath things nobody told you about

Vite doesn't care what you build with. The same tool sits under React, Vue, Svelte and plain JavaScript, which is unusual. Most tooling arrives welded to one framework and dies with it.

So it spread past the people who chose it deliberately. Astro and SvelteKit are built on it. Nuxt uses it. Vue's own setup command produces a Vite project, and Angular uses it for the local development server. Name any of those in a proposal and Vite is in there, mentioned or not.

The React side moved too. The React team has since retired Create React App, the starting point most React tutorials used for years, and now points people at a framework instead, or at a build tool like Vite.

None of which makes it right for a project already running fine on something else. Webpack, the tool it mostly displaced, is still maintained, still runs an enormous amount of working software, and still handles awkward inputs nothing newer replaces directly. A quote treating a move as automatic is worth a question.

Where it stops

The limit isn't capability, it's category. Vite decides how your code becomes files. It has no opinion on how your product is organised: where the pages live, how a web address maps to a screen, how data gets fetched, what happens when somebody signs in. Naming Vite and nothing else leaves all of that open.

The second limit follows. On its default settings a Vite project produces a single-page app: the browser downloads a near-empty page plus a program, and the content appears only once that program has run. Fine behind a login. Costly for a page you want found in search or opened on a weak connection. Server rendering is possible, but the usual way to get it is a framework built on Vite rather than the tool alone.

Third, the preview and the finished build take different routes through the tool, so occasionally something works in the preview and breaks in the built version. Nothing counts as done until it has been deployed and opened.

And it aims at current browsers by default. Support for older ones is an extra piece somebody adds. If a real share of your visitors are on old software, raise it at the start.

Who has to look after it, and the answer is close to nobody

There's no account to open, no seat to pay for, nothing installed on your server and no renewal date. It's released under the MIT licence, which puts no conditions on commercial use, and it's maintained by a team rather than by one person in their spare time. Once a build has finished, the tool sits idle.

What it asks for is attention once or twice a year, alongside everything else the project depends on. That's worth writing into an arrangement with whoever built it. Projects rarely get into trouble because the build tool was the wrong pick. They get into trouble because nobody touched them for three years, and then they won't build on a new machine at all.

So when a stack list arrives with ten names on it, this is the one to move past quickly. Spend the meeting on the framework sitting above it, on where your data lives, and on who's reachable to look after any of it in year two.