We get asked regularly why we recommend Next.js for almost every web project rather than a pure React SPA, Remix, Astro, or a backend-rendered framework like Django or Laravel. The answer has evolved as the framework has matured — here is where we have landed and why.
The problem with the obvious alternative: React SPA
The default choice for many JavaScript teams is still a Create React App or Vite React SPA with a separate backend API. This setup has real advantages: clear separation of concerns, simple frontend deployment (static files on a CDN), and a familiar mental model.
The problems accumulate over time:
SEO. A React SPA serves an empty HTML shell and renders content with JavaScript. Google can index JavaScript-rendered content, but it is slower, less reliable, and consistently underperforms server-rendered HTML in rankings. For any page that needs to rank — landing pages, service pages, blog posts, product pages — this is a meaningful disadvantage that compounds over months.
Performance perception. Users see a blank page or loading spinner before any content appears. The Time to First Contentful Paint is the time for JavaScript to download, parse, and execute. On slow connections or low-end devices — which account for the majority of global web traffic — this is noticeably slow. Large SPA bundles that accumulate over time make this worse.
Data fetching complexity. As applications grow, managing loading states, caching, error boundaries, and request waterfalls in client-side code becomes genuinely complex. Libraries like React Query help, but the underlying model of fetching everything from the client has inherent limitations.
Why Next.js App Router solves these specifically
The App Router, introduced in Next.js 13 and production-ready from 14, gives us tools to address each of these at the framework level:
React Server Components render on the server and send HTML to the browser. The browser receives fully formed content rather than an empty shell — the browser never needs to execute JavaScript to render the initial page. For a marketing page or blog post, this means the crawler and the user both see the content immediately. The JavaScript bundle sent to the browser is dramatically smaller because server components contain zero client-side JavaScript.
Streaming allows the server to send content progressively — critical content (header, above-the-fold text) arrives in milliseconds while slower content (data-dependent sections) loads in parallel. Users see something useful almost immediately regardless of backend response time.
The `loading.tsx` and `error.tsx` conventions provide structured handling for loading and error states without wrapping every component in try/catch or loading conditionals. Layouts persist between navigations — the nav and sidebar don't re-render and re-fetch when a user navigates between pages.
Built-in image optimisation via `next/image` — automatic WebP conversion, responsive srcset generation, lazy loading, and blur placeholders — eliminates a class of Lighthouse performance issues that would otherwise require significant custom tooling.
API routes and Server Actions allow backend logic to live in the same codebase. For most projects, this eliminates the need for a separate backend server for form handling, data mutations, and simple data fetching. When a full backend is needed (complex domain logic, separate scaling, multi-client API), we build it separately — but for the common case, keeping server-side code colocated with the page that uses it reduces operational overhead significantly.
The SEO advantage is measurable
We have rebuilt two client sites from React SPA to Next.js App Router in the past year. In both cases:
- Google Search Console showed new pages indexed within 2–3 days vs 2–3 weeks previously - Core Web Vitals scores moved from "Poor" or "Needs Improvement" to "Good" across all metrics - Organic traffic increased 40–80% within three months, with no other SEO changes
The performance difference on real user hardware is also measurable — particularly on mid-range Android devices and in markets where average internet speeds are lower. Lighthouse is a useful proxy but real-user Core Web Vitals data from the CrUX dataset reflects the experience for actual users on actual networks.
When we choose something else
Astro when the site is entirely or almost entirely static content with minimal interactivity. Astro's islands architecture ships zero JavaScript by default, making it genuinely faster than Next.js for content-only sites. We use it for documentation sites and marketing pages that have no dynamic data requirements.
A separate backend (FastAPI, Express) when the API needs to be consumed by multiple clients — mobile app, web app, third-party integrations — or when the backend has significant computational requirements (ML inference, data processing) that are better isolated from the web serving infrastructure.
Remix occasionally, for applications where the form-based mutation model maps particularly well to the use case. Remix's loader/action model has genuine advantages for traditional CRUD applications with complex server-side form validation.
Plain static HTML for landing pages with extreme performance requirements where even Next.js's JavaScript overhead is unwanted. This is rare but occasionally the right answer.
The practical advantage: the ecosystem
Next.js is deployed on Vercel (the company that maintains it), and the Vercel platform has made zero-configuration deployment, preview URLs for every pull request, and automatic performance analytics available with a few clicks. For client projects where time-to-deployment matters, this is a real advantage.
The ecosystem around Next.js — Auth.js for authentication, Prisma for database access, tRPC for type-safe APIs, Stripe's official Next.js integration — is the most mature in the JavaScript web development space. Using well-maintained integrations rather than building authentication or billing from scratch reduces development time and security risk.
We have standardised on Next.js not because it is the most interesting framework to work with but because it consistently produces the best outcome for clients: fast pages, good rankings, code that a new engineer can understand, and a deployment process that works without maintenance. Those outcomes are what we get paid to deliver.
If you are evaluating frameworks for an upcoming project, [reach out](/contact) — we are happy to give a specific recommendation based on your use case.