React vs Next.js: which to choose in 2026

The honest answer: for any new web app you're shipping in 2026, start with Next.js. React alone wins for embedded widgets, Electron desktop apps, and internal tools where you don't care about SEO. For everything else, Next.js gives you the things you'll add later anyway.

This is the decision every founder and senior engineer faces when starting a project. We'll lay out the trade-offs honestly, name the situations where each wins, and skip the "Next.js is just React with extras" framing that's true but useless.

React in 2026 (the library)

React is a UI library. It renders components and handles state. That's it. You're responsible for:

• Routing (React Router, Wouter, or hand-rolled)
• Server-side rendering (you set up Vite + a Node server, or you skip SSR)
• Build tooling (Vite, Webpack, Turbopack)
• Deployment (any static host, plus a backend if you need one)

It's the right pick when you want maximum control or you're working in an environment that already has its own framework (Salesforce, Shopify, Electron, an existing PHP monolith).

In 2026, React 19 added concurrent features, server components, and the use() hook. Most of those features are easier to access through Next.js, but the underlying library has them.

Next.js in 2026 (the framework)

Next.js is a full-stack framework built on React. App Router (the modern approach) gives you:

• File-system routing
• Server components by default
• Server Actions for mutations
• Streaming SSR with Suspense
• Built-in image, font, and script optimization
• API routes (no separate backend needed for simple cases)
• Vercel deploy in one command (or self-host on Node)

The trade-off: more opinions, less control. The framework decides how routing works, how data fetching works, where the boundary between server and client sits.

For 2026 it's the default for SaaS apps, marketing sites, blogs, and most B2B web products. The cost of starting with React-alone and adding the missing pieces later is consistently higher than starting with Next.js.

Head-to-head comparison

Factor	React (alone)	Next.js
Initial setup	Vite + manual choices (~2 hours)	create-next-app (~5 minutes)
SSR / SEO	DIY (Vite + Express) or skip	Built in, default
Routing	React Router, Wouter, or DIY	File-system, built in
API backend	Separate Node/Python service	API routes in same project
Image optimization	Sharp + DIY pipeline	Built-in <Image> component
Deploy target	Any static host + backend	Vercel one-click; self-host fine
Bundle size	Smaller for pure SPAs	Larger by ~30-40 KB but tree-shaken
Learning curve	One library	One library + framework conventions
Best fit	Widgets, Electron, internal tools	SaaS apps, marketing sites, blogs

When to choose React alone

Pick React (without Next.js) in these specific situations:

1. You're building a widget that lives inside another platform. Salesforce Lightning, Shopify storefronts, Confluence apps. The host platform owns routing and SSR. Next.js adds weight you don't use.

2. You're shipping a desktop app via Electron. No browser, no SEO, no SSR matters. Plain React + Vite is faster to build and ship.

3. You're writing an internal tool with no public surface. Internal admin dashboards behind auth don't need SEO. If you also don't need a backend (or have one already), Next.js is overkill.

4. You have a hard build-time constraint. Some teams can't justify the bundle weight of a framework. Pure React + Vite is leaner. This matters for embedded scenarios more than typical web apps.

When to choose Next.js

Pick Next.js when any of these apply:

1. SEO matters. Marketing sites, blogs, public-facing dashboards, e-commerce. Next.js gives you server rendering, metadata APIs, sitemaps, and OG image generation built in. Trying to add these to a React SPA later is painful.

2. You want one project for frontend + light backend. API routes handle auth, webhooks, simple CRUD without a separate Node service. For most SaaS MVPs this saves a meaningful amount of plumbing.

3. You're going to deploy to Vercel or a similar platform. The build pipeline is engineered around Next.js. Static and dynamic content cohabit cleanly.

4. You'll need image optimization, font loading, or middleware later. Building these from scratch on a Vite + React project takes weeks. Next.js gives them in one config file.

5. You're hiring engineers. The labor market in 2026 has more Next.js engineers than ever, and they expect to find an App Router codebase. Your hiring funnel widens.

The third option most people miss

If you're a non-technical founder reading this, the actual decision isn't React vs Next.js. The decision is: do you have someone who can ship the right one for your project?

Every engineer on Cadence is AI-native by default and fluent in both stacks. Median time to first commit is 27 hours. For the ~85% of new web projects where Next.js wins, you can book a Next.js engineer on Cadence in 2 minutes; for the React-alone scenarios, book a React engineer instead.

Each booking starts with a 48-hour free trial. Weekly billing from $500 (junior) to $2,000 (lead) per week. Cancel any week.

Performance: what actually matters

Next.js apps load faster than equivalent React SPAs in 90% of real-world cases. The reasons are mechanical, not mystical:

• Server rendering means the first paint is HTML, not a JavaScript bundle that has to download and execute first
• App Router code-splits per route, so users only download what they're seeing
• Image and font optimization happen at build time, not in the browser

For an interactive React SPA you can match Next.js performance with effort: pre-rendering with Vite, lazy loading, manual image optimization, manual code splitting. Most teams don't. That's the practical reason Next.js wins on performance, not the rendering model itself.

Common mistakes when picking between React and Next.js

Five patterns we see consistently when teams pick the wrong one (or the right one badly):

1. Picking React because "Next.js feels heavy". The instinct is wrong but understandable. Pure React + Vite feels lighter at month 1. By month 4 the team has reinvented routing, image optimization, SSR, and an API layer; the project is now heavier and worse-architected than a default Next.js setup would have been.

2. Picking Next.js for an Electron app. Electron loads local files; there's no SEO surface and no server. Next.js's SSR machinery is dead weight in this context. Vite + React is the right pick.

3. Skipping App Router in 2026. The Pages Router still works, but it's the legacy path. New Next.js projects in 2026 should be App Router unless there's a specific reason. Hiring is also easier; new engineers expect App Router conventions.

4. Building a SPA instead of using Server Components. Putting "use client" at the top of every component throws away half of Next.js's value. Default to server components; mark client only what needs interactivity.

5. Self-hosting Next.js without understanding the trade-offs. Vercel is the smoothest path. Self-hosted Next.js on Node works fine for most cases but loses the build-time optimizations Vercel provides. Worth it for cost or sovereignty reasons; not worth it just for "we don't trust Vercel."

Stack decisions you'll make alongside this

Picking Next.js (or React) is one decision. The connected ones:

• Database: Postgres (via Neon, Supabase, or Railway) is the default in 2026 for new SaaS apps
• ORM: Drizzle for type-driven, Prisma for ergonomic, Kysely for query-builder fans
• Auth: Clerk (free up to 10k MAU, then $25/mo + per-MAU), Auth0, or NextAuth
• Payments: Stripe is still the default; Paddle and Lemon Squeezy for international tax handling
• Hosting: Vercel (Next.js native), Railway, or Fly.io for self-hosted Next.js
• AI tooling: Cursor, Claude Code, Continue. Every Cadence engineer is fluent in these as part of the AI-native baseline.

Build vs Buy vs Book is our free tool that runs through these decisions for any feature you're considering.

Try it for an actual project. Describe what you're building on Cadence and we'll match you to four pre-vetted React or Next.js engineers within hours. 48-hour free trial; weekly billing only kicks in if they're shipping.

FAQ

Is Next.js better than React?

Next.js is built on React. The question is whether you need a framework on top of the library. For most web projects in 2026, yes; you'll add server rendering, routing, and image optimization eventually anyway. For widgets, Electron apps, or internal tools, plain React is fine.

Should I learn React or Next.js first?

Learn React first. Spend a week on hooks, components, state. Then move to Next.js for routing, server components, and data fetching. Next.js makes more sense once you understand what it's automating.

Can I migrate a React app to Next.js?

Yes, but it's not a one-day job. Plan for: routing migration (React Router to App Router), data-fetching migration (client useEffect to server components), and bundler change. Realistically a 2-4 week migration for a mid-sized app. Worth it if you're hitting SEO or performance walls.

Is Next.js overkill for a simple landing page?

Not really. create-next-app to deployed-on-Vercel is under 10 minutes. The "overkill" worry made sense in 2019; in 2026 the framework is the simpler choice for marketing sites because static export + ISR + image optimization are all built in.

What about Remix or Astro?

Remix (now Remix v3) is a credible alternative to Next.js for data-heavy apps; the form-first model is genuinely better for some use cases. Astro is the right pick for content-heavy sites that don't need much interactivity. For pure SaaS apps, Next.js still wins on ecosystem.

Will Next.js still be the default in 2028?

Probably. The architectural bets (server components, streaming, file-system routing) are aligned with where React itself is going. The risk isn't the framework; it's vendor coupling to Vercel. Self-hosting Next.js on Node is supported and works fine if you want to stay portable.