React with Vite or Next.js? Answer three questions and it decides itself

This is the decisive question and it is usually answered too casually. If marketing pages, case studies, documentation or a public catalogue need to appear in search results, you need HTML that exists before JavaScript runs. Next.js gives you that as a default. A client-rendered Vite app gives you an empty container and a dependency on Google's rendering queue.

I learned the cost of getting this backwards on my own portfolio. It was a Vite single-page app, and Search Console reported nineteen of twenty pages as discovered but not indexed. Every URL returned the same empty shell with the same title. Fixing it meant adding a prerendering step and eventually moving to Next.js — work that would have been free if the first decision had been right.

For an internal dashboard, the answer is a logged-in user who opens it every morning and has everything cached. A slow first load costs them a few seconds once. Client-side rendering is entirely reasonable.

For anything public-facing, the first load is a stranger on a phone on a mediocre connection deciding whether your product is worth their attention. Server rendering the initial view materially changes what they see in the first second.

This is why the two products I would build differently are almost the same size. A CRM behind a login: Vite. A marketing site with a product catalogue: Next.js. Not because one framework is better, but because the visitors are different people in different situations.

Next.js is a server framework. That means a Node runtime to deploy, caching semantics to understand, and a meaningful distinction between server and client components that will confuse anyone who has only written client React. On a managed platform much of this disappears, which is why the honest answer is usually "yes, fine". On self-managed infrastructure with no one who wants to own it, that is a real cost.

Vite builds static files. Any static host serves them. There is no runtime to operate, no cold starts and no server-client boundary to reason about. For a team of one shipping an internal tool, that simplicity is worth something.

Bundle size and benchmark numbers get quoted constantly and rarely decide anything real. At the scale most projects operate, your bundle is large because of what you imported, not because of which build tool assembled it.

What does matter, and is easy to underestimate, is that these are not equally reversible choices. Moving from Vite to Next.js means restructuring routing, data fetching and rendering. Moving the other way means giving up server rendering, which you probably adopted for a reason. Spend the afternoon on this one.