Vanilla React (Create React App, Vite) and Next.js solve different problems despite looking similar. Confusing the two is the most expensive architecture mistake we see on new React builds. This guide is the conversation we have with every team weighing the two before they write a line of code.
The short version: if your application is a logged-in product where the UI is the product (a SaaS dashboard, a complex internal tool, a real-time interface), vanilla React with Vite gives you the right defaults. If your application is anything customers find through Google — marketing site, content engine, e-commerce, product pages — Next.js's SSR, ISR, and Server Components are not optional. Below we walk through the five real differences that determine the choice.
Difference 1 — SEO and crawlability
Vanilla React with Vite ships a JavaScript bundle that renders the page in the browser. The HTML the server sends is roughly: <div id="root"></div>. Google's crawler can execute JavaScript and read the rendered content, but the indexing pipeline is slower, less reliable, and known to miss content on JavaScript-heavy pages. For any site where organic search is a meaningful acquisition channel, this is a hard problem.
Next.js renders the page on the server and ships full HTML to the browser. Search crawlers read the page content directly — instantly indexable, no JavaScript execution required. Core Web Vitals are dramatically better because the user sees content before the JavaScript bundle has even downloaded. For SEO-led businesses, this is decisive.
If your application has zero SEO requirements (a logged-in tool, a B2B dashboard, an internal admin), this difference does not matter. If SEO matters at all, Next.js wins by default.
Difference 2 — First-load performance
Vanilla React's first-load performance is constrained by bundle size and hydration time. A typical Create React App ships 200 to 500 KB of JavaScript before the user sees anything. Even with Vite's improved bundler, a single-page app waits for the JS to download, parse, execute, and render before painting. On mobile networks, this can mean 3 to 5 seconds to first contentful paint.
Next.js with Server Components ships HTML first and JavaScript second. The user sees content in 800 ms to 1.2 seconds; interactivity arrives a few hundred ms later as the framework hydrates. LCP under 1.5 seconds is achievable on a real-network mobile device, which vanilla React almost never matches without serious engineering work.
For applications where users will engage for 10 to 30 minutes (dashboards, editors, productivity tools), first-load performance matters less — the initial 3-second wait amortises across the session. For marketing sites, product pages, and content where users bounce after 30 seconds, every 200 ms of first-load delay costs conversion.
Difference 3 — Where data lives
Vanilla React fetches data on the client. Every API call originates from the browser, hits a backend, returns data, then the component renders. This pattern is excellent for interactive applications where the data changes constantly — charts, editors, real-time dashboards. It is the wrong pattern for content that does not change per-user.
Next.js Server Components fetch data on the server. The data is rendered into HTML before the page reaches the browser. No client-side loading spinner, no waterfall of API calls, no third-party API key shipped to the browser. For content-driven pages, this is dramatically simpler and faster.
Most real applications need both patterns. Next.js supports both natively. Vanilla React forces you to build the server-side rendering yourself if you ever need it (or to abandon the architecture and migrate).
Difference 4 — Team familiarity
This is the difference most architecture decisions skip. Next.js's App Router with React Server Components is a genuinely new mental model. The line between server code and client code is not where developers expect it. Server actions, streaming, parallel routes, intercepting routes, error boundaries with reset — the patterns are powerful but require team investment to use well.
If your team has shipped Next.js apps before and knows the patterns, the velocity is dramatic. If your team is mid-level React engineers who have not used the App Router, the learning curve is real and the first 6 to 10 weeks will move slower than the equivalent vanilla React build.
We do not recommend Next.js to teams without prior Next.js experience unless the project timeline accommodates the learning curve. We do recommend vanilla React + Vite to teams who need to ship fast and have stronger React fundamentals than Next.js framework fundamentals.
Difference 5 — Deployment target
Vanilla React with Vite produces a static bundle. Deploy to any CDN: S3 + CloudFront, Cloudflare Pages, Netlify, Vercel, your own server. The bundle is portable; no vendor lock-in.
Next.js's full feature set (Server Components, server actions, ISR, edge functions, image optimisation) works best on Vercel. It works on other hosts (Netlify, AWS Amplify, Cloudflare Pages, self-hosted Node) but with degraded feature support, more configuration, or worse performance. For teams that want infrastructure flexibility, this is a real cost. For teams happy on Vercel, it is a feature.
Where vanilla React legitimately wins
Logged-in product applications. SaaS dashboards, internal tools, B2B admin interfaces. SEO does not matter; first-load performance is amortised across a long session; the team builds against a real backend API. Vanilla React + Vite + React Router + TanStack Query is the canonical stack and works beautifully.
Real-time and interactive apps. Whiteboards, editors, video tools, multiplayer applications. The complexity of Next.js Server Components fights you here; vanilla React + Vite gives the unconstrained client-side control these apps need.
Mobile apps via React Native. If the React app shares code with a React Native mobile app, vanilla React is the natural choice because React Native is closer to vanilla React than to Next.js.
Teams who deploy to anywhere except Vercel. If your infrastructure is AWS, GCP, Azure, or self-hosted, vanilla React with Vite gives the cleanest deploy story.
Where Next.js legitimately wins
Marketing sites and content engines. SEO matters; content needs to be indexable; Core Web Vitals affect rankings. Next.js with App Router + Server Components is the right answer.
E-commerce storefronts. Product pages need to render fast and rank in search. Whether the catalogue lives in Shopify, Sanity, Contentful, or a custom backend, Next.js fetches it on the server and serves it as HTML.
Sites with mixed content + product. A SaaS company with marketing pages, a blog, a dashboard, and an in-app editor — Next.js handles the content side natively and embeds the dashboard / editor as client components where needed.
Apps where Core Web Vitals are a business metric. If LCP under 1.5s is a target and you are starting from scratch, Next.js gets you there faster than vanilla React.
What about Remix, Astro, TanStack Start?
Remix is a serious competitor to Next.js, with a slightly different opinion on data loading (route-level loaders rather than React Server Components). For applications that lean heavily on forms, mutations, and progressive enhancement, Remix is often the cleaner choice. We build with Remix when clients have a preference; the architecture decisions are similar.
Astro is excellent for content-led sites where most pages have zero interactivity (marketing sites, blogs, documentation). Astro ships zero JavaScript by default and lets you embed React (or other framework) components only where needed. For a publication or marketing site with light interactivity, Astro is faster to build and ships faster pages than Next.js.
TanStack Start is the newest entrant, built around TanStack Router and Query. Promising for client-heavy applications that want server-side rendering without Next.js's opinions. We have built one production project on it; the pattern is solid but the ecosystem is younger.
The honest decision framework
Three questions usually resolve the choice:
Question 1: Does the application need to rank in search results? If yes, pick Next.js (or Remix, or Astro for content-led sites). If no, vanilla React + Vite is simpler.
Question 2: How long is the typical user session? Under 1 minute means first-load performance dominates — pick a framework with SSR. Over 10 minutes means amortised performance dominates — vanilla React is fine.
Question 3: Does your team know Next.js patterns? If yes, Next.js is the modern default for new builds. If no, factor 6 to 10 weeks of learning into the schedule, or pick the stack your team can ship on confidently.
What we ship at Dream Steps
Roughly 55% of our React work is Next.js (mostly App Router, mostly Vercel-deployed). Roughly 25% is vanilla React with Vite for product applications. Roughly 12% is Remix for content-led builds where the client prefers it. The remaining 8% is Astro, TanStack Start, or older Next.js Pages Router stores we have inherited.
When clients come to us with the decision unmade, we recommend the stack that fits the business in three years — not the stack that is trending on Twitter this month. We will tell you honestly if your application does not need a framework, and we will tell you honestly if your team is not ready for Next.js's patterns.
Common questions
Is Next.js faster than vanilla React?
For first-load performance on content-driven pages, yes — Next.js’s server rendering ships HTML before the JavaScript bundle, so LCP and FCP are dramatically better. For amortised performance over a long user session (10+ minutes), the two are roughly equivalent because both run as React on the client after hydration. The framework matters most on the FIRST few seconds; after that, performance is determined by your component code, not the framework.
Can I migrate from vanilla React to Next.js later?
Yes, but it is a rebuild rather than a migration. Components transfer; routing, data fetching, and any client-side state management need to be reworked for Next.js’s patterns. Plan for 60 to 80% of the time of a fresh Next.js build, plus 2 to 3 weeks of unanticipated work where vanilla React patterns do not map cleanly to App Router (especially around context providers, custom hooks that assume client-only rendering, and third-party libraries that are not SSR-compatible).
What about Next.js Pages Router vs App Router?
Pages Router is mature, well-understood, and works without React Server Components. App Router is the modern direction — Server Components, server actions, streaming, parallel routes. For new builds in 2026, App Router is the right default. For existing Pages Router apps that work well, migration is optional, not urgent. We have a separate article on App Router vs Pages Router decision-making.
Should I use Remix or Astro instead of Next.js?
Remix is a serious alternative for form-heavy applications and progressive-enhancement-led builds; we use it when clients prefer it or when the project’s data model fits Remix’s loader pattern better. Astro is excellent for content-led sites where most pages have minimal interactivity — marketing sites, blogs, documentation, publications. For mixed content + interactive product, Next.js’s flexibility usually wins. The choice depends on what the app actually has to do, not framework popularity.
Do you white-label React / Next.js development for agencies?
Yes. Roughly 35% of our React work is built for other agencies and consultancies under NDA — white-label engagements, agency-of-record dedicated pods, and capacity overflow when your in-house team is full. We work in your tooling, code ownership transfers to your repos, and time zones overlap with the UK, EU, and US workday. Standard sub-contract and IP transfer in place before any work begins.
Need help choosing between vanilla React and Next.js?
Send us a brief about the application, the team, and where you want to be in three years. We will come back with an honest recommendation.