Why We Chose Vite Over Next.js for DBF Nexus

When we started building the DBF Nexus website, the default choice for most React projects in 2026 is Next.js. It has SSR, file-based routing, image optimization, and a massive ecosystem. So why did we go with Vite instead?

The Decision Criteria

We evaluated three things: development speed, deployment simplicity, and whether we actually needed SSR. The answer to the third question decided everything.

Do We Need SSR?

Our website is a marketing site with a customer portal. The marketing pages are static content that changes maybe once a week. The portal is behind authentication and doesn't need SEO. Neither use case requires server-side rendering on every request.

What we needed was prerendering — generate static HTML at build time so search engines see fully rendered pages. We built a custom Puppeteer script that prerenders all 40+ routes during the build process. Total prerender time: under 30 seconds.

HMR Speed: Night and Day

Vite's Hot Module Replacement is nearly instant — typically under 50ms. During a full day of development, you save minutes of accumulated wait time compared to Next.js's webpack-based dev server. When you're iterating on animations, responsive layouts, or interactive components, that speed compounds.

Metric	Vite	Next.js
Dev server cold start	~400ms	~3s
HMR update	~30ms	~300ms
Production build	~6s	~25s
Bundle size (our site)	~210 KB gzipped	~280 KB gzipped

Deployment Simplicity

With Vite, our build output is a static dist/ folder. We can deploy it anywhere — Vercel, Netlify, a CDN, or even a basic web server. No Node.js runtime needed in production. No edge functions for routing. No cold starts.

With Next.js, you need a Node.js runtime (or Vercel's proprietary edge runtime) to handle SSR, API routes, and middleware. That adds complexity, cost, and vendor lock-in.

What We Do Use Alongside Vite

• React Router v6 — client-side routing with lazy-loaded routes
• React Helmet Async — per-page SEO meta tags
• Supabase Edge Functions — serverless API endpoints (auth, email, AI)
• Custom prerender script — Puppeteer-based static HTML generation
• Vercel — hosting with SPA rewrite rules

When We Would Choose Next.js

Next.js is the right choice when you need real-time SSR (e.g., personalized content per user), built-in API routes that share the same codebase, or when your team is already deep in the Next.js ecosystem. For content-heavy sites with thousands of pages, Next.js's ISR (Incremental Static Regeneration) is genuinely useful.

For our case — a marketing site + authenticated portal with Supabase as the backend — Vite was the simpler, faster, and more flexible choice. We haven't regretted it once.

Interested in how we built the rest of the stack? Read The Stack Behind DBF Nexus Portal.