Why we chose Vite over Next.js
Next.js is excellent, but our apps are authenticated SPAs and an embeddable widget backed by a GraphQL API. Here is why Vite was the better fit.
This is not a “Next.js is bad” post. Next.js is excellent at what it is built for. This is a story about matching the tool to the shape of the apps we actually ship, and for us that shape pointed at Vite.
What we are actually building
Our apps are an admin dashboard behind a login, an embeddable booking widget that drops into other people’s sites, and a marketing site. Two of the three are pure client-side apps where SEO and server rendering do not matter. All of them talk to a single GraphQL API that already owns data fetching and business logic.
Where Next.js shines, and why we did not need it
Next.js earns its weight on content-heavy, SEO-critical sites that benefit from server-side rendering, server components, and its built-in data layer. Our dashboard sits behind auth, so there is nothing to pre-render for search engines. Our data already lives behind GraphQL, so we did not need API routes or a server data layer baked into the framework. Paying for a server runtime and a framework’s conventions to get features we would not use is a poor trade.
Vite is a build tool, not a framework
That is exactly why it fits. Vite gives us an extremely fast dev server (instant start, near-instant hot reload) and a lean production build, then it gets out of the way. We pick our own router, our own data layer, and our own structure. For a team that already has strong opinions and a shared design system, a build tool that does not impose a framework is a feature, not a gap.
The embeddable widget settled it
The booking widget has to embed cleanly into websites we do not control. That means a small, self-contained bundle with no server runtime and no framework-specific hosting requirements. Vite builds exactly that: static assets I can drop behind a CDN. Doing the same with a full server framework would be fighting the tool the whole way.
It keeps the monorepo uniform
Every app in our Turborepo monorepo is a Vite app with the same build story: fast dev, static output, deploy to S3 and CloudFront. One mental model across all of them, one consistent pipeline, and the shared design system plugs into each the same way. Adding a server framework into that mix would mean a second, heavier deployment model for little benefit.
The honest tradeoff
We give up first-class SSR and the conveniences Next bundles in. If we later build something genuinely content-first and SEO-driven, Next.js or Astro is the right call for that piece, and a monorepo makes adding it painless. Choosing Vite was never a verdict on Next.js. It was choosing the tool that matched the apps in front of us.