The Framework That Became the Default
Next.js has become the default React framework for a wide range of projects — from simple marketing websites to complex enterprise applications — partly because it’s genuinely excellent for the use cases it was designed for and partly because its mindshare has grown to the point where it’s chosen without conscious comparison to alternatives. ‘We’ll use Next.js’ has become the default architectural decision in the same way that ‘we’ll use React’ became the default component model decision — a choice made from familiarity and ecosystem momentum rather than from explicit evaluation.
The question worth asking before starting a project with Next.js is whether the project’s requirements actually need what Next.js provides, or whether a simpler tool — a static site generator, a plain React SPA, a server-rendered framework with less complexity — would produce the same result with less overhead. Next.js adds value in specific scenarios; it adds complexity without value in others.
What Next.js Actually Provides
Next.js provides a React framework with server-side rendering (SSR), static site generation (SSG), incremental static regeneration (ISR), React Server Components (RSC), file-based routing, API routes, image optimisation, and the deployment-optimised infrastructure that Vercel (Next.js’s creator and primary deployer) provides. This feature set addresses the core limitations of client-side React SPAs (poor initial load performance, poor SEO for dynamically rendered content) while maintaining the React development model.
The rendering flexibility is Next.js’s defining strength: different pages in the same application can use different rendering strategies (fully static for marketing pages, server-rendered for personalised dashboard pages, client-side for highly interactive application sections) without requiring separate applications. For applications with mixed rendering requirements, this flexibility produces better performance than a uniform rendering strategy would allow.
When Next.js Genuinely Makes Sense
Next.js is the right choice when: the application has mixed content (some pages should be statically generated for maximum performance, others require server-side rendering for personalised content, others require full client-side interactivity), SEO matters for dynamic content (product pages, blog posts, content that needs to be indexed with the full rendered content), the application benefits from API routes co-located with the front end, and the team is already proficient in React and wants the additional capabilities that Next.js provides without switching to a different paradigm.
E-commerce sites (static category pages, server-rendered personalised checkout), content-driven sites with large volumes of pages (ISR allows updating individual pages without rebuilding the entire site), and SaaS applications with public marketing pages alongside private authenticated app sections are the use cases where Next.js’s rendering flexibility provides tangible advantages over simpler alternatives.
When Simpler Alternatives Win
A static marketing site (company website, product landing pages, documentation) doesn’t need Next.js’s server-side rendering or API routes — Astro, Hugo, or 11ty generate static HTML faster, with smaller JavaScript bundles, and with simpler deployment than Next.js for content that doesn’t change per request. A single-page application with all data loading client-side after authentication doesn’t benefit from Next.js’s server-side rendering (the authenticated content isn’t public and doesn’t need SSR for SEO); vanilla React with Vite provides a simpler, faster development experience for this use case.
The cases where Next.js adds complexity without proportional value: projects where static generation covers all content needs, where no API routes are required, where the team doesn’t have existing React expertise and would benefit from a lower-complexity framework, and where the deployment target isn’t Vercel (Next.js’s full feature set, particularly ISR and edge runtime features, works best on Vercel; deploying Next.js elsewhere involves configuration complexity that eliminates some of its convenience advantages).
The Practical Decision Framework
The questions that determine whether Next.js is the right choice or whether a simpler alternative would serve better: Does the application have content that needs server-side rendering for SEO or personalisation? (If no: a static site generator or client-side SPA is simpler.) Does the application mix static and dynamic content that requires different rendering strategies on different pages? (If yes: Next.js’s rendering flexibility is valuable.) Is Vercel the deployment target? (If no: some of Next.js’s most useful features require additional configuration on other platforms.) Is the team already proficient in React? (If no: the learning curve of Next.js plus React plus the full-stack concepts it introduces may exceed what the project justifies.)
The honest answer for the majority of projects that default to Next.js: many of them would be adequately served by simpler alternatives — a static site generator for content sites, plain React with Vite for single-page apps, Astro for content-heavy sites with islands of interactivity. The projects where Next.js specifically adds value are real and common; they’re also a subset of the projects that currently use it. Choosing Next.js consciously after evaluating whether the project’s requirements justify it produces better architectural decisions than choosing it reflexively as the React default.
