Next.js is used by 59% of React developers. It is also the most complained-about framework in the State of JS 2025 survey, with 17% holding negative opinions: up from 11% the year before. That gap between adoption and satisfaction is worth understanding before you commit to it for your next project.

What Next.js actually gives you

Next.js is a framework on top of React. The things it genuinely solves:

• Server-side rendering (SSR): HTML is generated on the server before it reaches the browser. This is critical for SEO and for pages where initial load time matters to users. Plain React renders in the browser (CSR), which means Google and other crawlers see an empty page until JavaScript executes.
• File-based routing: Create a file in the app/ directory and it becomes a route. No router configuration. No manual route registration.
• API routes: Backend logic lives alongside the frontend. You do not need a separate Node server for simple API endpoints.
• Image optimization: The next/image component automatically serves WebP, resizes to the displayed size, and lazy loads. This is real work you would otherwise do manually.
• Opinionated defaults: Routing, rendering strategy, data fetching patterns: you get conventions rather than blank-page decisions.

The legitimate complaints

The criticism from the developer community is not unfounded. The main gripes:

Vercel lock-in. Next.js is maintained by Vercel. Features like Edge Middleware, advanced caching directives, and certain server-side behaviors work best (or only) on Vercel. Deploying to a VPS, Railway, or AWS requires more work, and some features behave differently or are unavailable entirely. 36% of developers in the State of JS survey expressed concern about this specific dynamic.

Complexity for simple sites. If you are building a marketing site, a landing page, or a small web app with modest interactivity, Next.js introduces more configuration and mental overhead than the project needs. The App Router (current default) has a learning curve that is not trivial.

React Server Components confusion. The App Router blurs the line between server and client code in ways that trip up developers who are not aware of the distinction. It works well once you understand the model, but the error messages when you get it wrong are not always helpful.

When Next.js is the obvious choice

If SEO matters to the business, Next.js is the right call. Marketing sites, blogs, e-commerce, anything where Google needs to index content and rank it. Client-side React renders an empty shell until JavaScript executes. That is a problem for crawlers and for perceived load time on slow connections. Server-rendered HTML solves both.

Full-stack web apps where the backend and frontend need to live in the same codebase also benefit. API routes, server actions, and the App Router together mean a small team can ship a complete product without maintaining a separate backend. The image optimization and OG image generation alone are worth it if you would otherwise have to build that separately.

When plain React with Vite is the better pick

The one I always recommend for internal tools and admin dashboards: plain React with Vite. If the app lives behind a login, SEO is irrelevant. Server-side rendering adds complexity with no benefit. A Vite React app is simpler to build, simpler to deploy, and easier to hand off to another developer because there are fewer conventions to understand.

Same goes for apps where a separate API backend already exists. If the frontend is just consuming REST or GraphQL endpoints, you do not need Next.js API routes. You are adding a framework to solve a problem you do not have. Vite builds a static bundle you can serve from any CDN or static host.

What about Astro?

Astro is the serious competitor nobody expected. It builds pages as static HTML by default and only hydrates JavaScript for components that actually need interactivity. For content-heavy sites, blogs, and documentation, it ships 95% less JavaScript than a Next.js equivalent. It is not a replacement for Next.js in everything: it does not handle server-side API routes the same way, and full SaaS apps are not its primary use case. But for marketing sites where you currently reach for Next.js by default, Astro is worth comparing.

The actual decision framework

The React Compiler reaching v1.0 stability in late 2025 improved plain React's performance significantly by eliminating the need for manual memoization. This narrows the performance gap between plain React and Next.js for client-side apps. It does not change the SSR argument.

TypeScript should be your default in either case. The State of JS 2026 survey called it officially: TypeScript has won. New projects without TypeScript are choosing technical debt from day one.