We recently migrated this very site off Create React App. CRA had been unmaintained for a while, the dev server had grown slow, and the tooling underneath it was frozen in time. That is the kind of forced move that makes you think hard about what you replace it with, because you do not want to do it again in two years. We landed on Vite with static-site generation through vite-react-ssg, and the decision turned less on benchmarks than on a single question: when the next forced move comes, how much of the stack will we have to tear out to satisfy it.
That question is the real subject of the Next.js versus Vite versus Remix debate. It is not which one is fastest or most popular. It is how tightly the pieces are bound together, and what that binding costs you later.
The actual tradeoff: coupling versus composability
The three options are not the same kind of thing, and pretending they are is where most comparisons go wrong.
Vite is a build tool. That is its whole job. It does not have an opinion about your router, your rendering strategy, or where your data comes from. You bring a router (React Router, TanStack Router), you pick a rendering mode (single-page app, static generation, server rendering), and you choose a data layer, and Vite bundles all of it quickly. The pieces are separate by design.
Next.js is a framework. It bundles the build tool, the router (file-system based), the rendering model (server components, streaming, the app router), data fetching conventions, and even a backend (route handlers, server actions) into one integrated whole. You do not assemble those parts. You adopt them together, and they are designed to be used together.
Remix, now folded into React Router, sits in the middle. It is a real framework with genuinely strong web fundamentals: nested routing, loaders and actions tied to routes, progressive enhancement, a respect for the platform that Next.js sometimes papers over. It is less sprawling than Next and more coherent than a pile of Vite plugins. But it is still a coupled framework. The routing, the data model, and the rendering come as a set.
Figure 1. A bundled framework fuses build, router, rendering, and data into one block you adopt whole. A composable setup keeps them as separate layers you choose and swap independently.
The question is not which tool is best. It is which parts of your stack you want welded together, and which you want to swap without a rewrite.
A side-by-side comparison
| Dimension | Vite | Next.js | Remix / React Router |
|---|---|---|---|
| What it is | A build tool | A full framework | A full framework |
| Coupling | Low, parts are separate | High, one integrated whole | Medium, routing and data as a set |
| Build and dev speed | Fastest, native ESM dev server | Good, faster since Turbopack | Good, Vite-based now |
| Rendering options | SPA, SSG, SSR, you choose | SSR and server components first | SSR-first, strong nested routing |
| Router | Your choice | Built in, file-system | Built in, nested |
| Backend | Bring your own | Included | Included |
| Lock-in | Low, swap layers piecemeal | High, conventions run deep | Medium |
| Ecosystem | Huge for the build tool itself | Largest, Vercel-backed | Solid, growing under React Router |
| Best for | Teams who value separation and portability | Fastest path to a full-stack app | Web-fundamentals teams wanting structure without Next's sprawl |
Build speed and developer experience
This is the least interesting axis, because all three are good now. Vite has been the speed leader for years thanks to its native ES modules dev server: it does not bundle your whole app on every change, so cold starts and hot updates stay fast as the codebase grows. That was a big part of why CRA felt painful and why the switch felt instant.
Next.js closed much of the gap with Turbopack, and for most teams the dev server is fast enough that it is no longer the deciding factor. Remix runs on Vite now, so it inherits the same quick feedback loop. If raw speed is your only concern, you will be happy with any of them. The differences that matter show up later, when the project is large and the requirements change.
Rendering options
Here the philosophies diverge sharply.
With Vite you decide the rendering model per project, and you can change your mind. Our site is static today: pages are generated at build time and served as flat files, which is exactly right for a marketing and content site. If we later needed server rendering for a part of the app, we could add it without abandoning the build tool or the router. The rendering strategy is a layer, not a foundation.
Next.js leads with server rendering and server components, and that is genuinely powerful. Streaming, component-level data fetching on the server, and tight integration with the router are real advantages for an application with a lot of dynamic, personalized, server-driven content. The cost is that the model is pervasive. The mental overhead of which code runs where, the server-client boundary, and the caching behavior are things you carry everywhere, even on pages that did not need any of it.
Remix takes the strongest stance on web fundamentals. Loaders and actions tied to routes, forms that work without JavaScript, and nested routing that maps to nested data are a clean model for content that lives on the server. If your product is fundamentally a set of server-rendered pages with forms and navigation, this is arguably the most principled of the three.
Lock-in and the cost of migrating off
This is the part teams underweight until they are living it, and it is where our CRA migration earned its lesson.
Migrating off Create React App to Vite was not painful, precisely because CRA was thin. It bundled, and that was mostly it. Our router, our components, and our data fetching did not care which tool packaged them, so swapping the packager was a contained change. The separation of concerns that CRA happened to have is what made it cheap to leave.
Migrating off Next.js is a different undertaking, because the framework reaches into everything. Your routing is its file system. Your data fetching uses its conventions. Your backend lives in its route handlers and server actions. Your rendering assumes its server-component model. Leaving means rewriting all of those at once, because they were never separable in the first place. That is not a flaw in Next.js. It is the direct consequence of integration, and integration is also what makes Next.js so pleasant on day one. You cannot have the tight coupling that makes it fast to start and also have it be cheap to leave. Those are the same property viewed from two ends of the project.
Vite asks for the opposite trade. You assemble more yourself up front (a router, a rendering setup, a data layer), and in exchange each of those stays swappable for the life of the product.
Ecosystem, and being honest about Next.js
Next.js has the largest ecosystem of the three, the most tutorials, the most hiring pool familiarity, and first-class deployment on Vercel that makes the path from code to production genuinely frictionless. Server components are a real advance, and for a team that wants a full-stack application running this week, Next.js is the fastest honest answer. If your team values a single well-trodden path over the freedom to deviate, it is the right default, and it is the right default for a lot of teams.
Vite's ecosystem is enormous, but it is an ecosystem of a build tool and its plugins, not of one prescribed way to build an app. That is the point and also the catch: you get composability, and you pay for it by making more decisions yourself.
When each is the right call
- Choose Next.js when you want the fastest path to a full-stack app, you are deploying to Vercel, server components fit your product, and you are comfortable adopting the framework's conventions wholesale. For many teams this is simply the correct default.
- Choose Remix (React Router) when your product is server-rendered pages with strong navigation and forms, you want real web fundamentals and nested routing, and you want a coherent framework without Next's full sprawl.
- Choose Vite when you value separation of concerns, you want to pick your router, rendering mode, and data layer independently, and you would rather assemble a stack you can change one piece at a time than adopt one you cannot.
For our own site, the deciding factor was not speed, though Vite is fast. It was that we never again wanted a forced migration to mean replacing the whole stack. We wanted the build tool to be just a build tool.
At Omnihash we make this call on real products, and the honest answer is that it depends on what you are optimizing for: speed-to-start, or the freedom to change your mind later. If you are weighing these three for something you are about to build, we are happy to talk through the specific tradeoff.