Next.js Alternatives: Remix, Astro, and NestJS Compared

Next.js alternatives worth a real look in 2026 are React Router, Astro, and NestJS. Each one solves a different problem. React Router (the framework that used to ship as Remix) swaps Next.js's file-based data fetching for route-level loaders. Astro trades React's client-side app model for islands of interactivity on mostly static HTML. NestJS isn't a frontend framework at all. It's a backend-only pick for teams whose "Next.js alternative" question was really about the API layer.

This guide compares all three against Next.js, with a CMS-fit note for each. Fetching content from a headless CMS is where these frameworks actually diverge in daily use, not in the marketing copy.

What Changed: Remix Is Now React Router

Search "Remix vs Next.js" today and half the results are stale. In 2024, the Remix team folded Remix into React Router. React Router 8 shipped in July 2026. The framework-mode template from npx create-react-router@latest is now the direct successor to what Remix used to mean as a standalone package. The old @remix-run/react package still exists for older projects. New work starts on React Router.

The concept survived the rename. Data still loads through route-level loader functions, not a page-level getStaticProps or getServerSideProps.

Next.js vs React Router: Loaders vs getStaticProps

Next.js splits data fetching by rendering mode. getStaticProps runs at build time and bakes data into static HTML. getServerSideProps runs per request instead. The App Router replaces both with plain fetch calls inside Server Components, cached or not depending on the options you pass.

React Router takes one path for every route. A loader function runs on the server, or in the browser for a client-only app, before the route renders. Its return value becomes the route's data. There's no separate static-vs-server decision to make up front.

// React Router loader
export async function loader() {
  const res = await fetch('https://api.draftbase.co/delivery/entries?templateId=blogPost');
  return res.json();
}

// Next.js App Router Server Component
async function Page() {
  const res = await fetch('https://api.draftbase.co/delivery/entries?templateId=blogPost', {
    next: { tags: ['blogPost'] },
  });
  const data = await res.json();
  return <BlogList posts={data.items} />;
}

CMS fit: React Router

React Router has no built-in ISR and no on-demand revalidation. Fresh content just means re-running the loader, which happens on every navigation by default. For a CMS-backed marketing site leaning on cached static pages, that's a real gap. For an app with account-gated content that's already fetching per request, the loader model beats juggling Next.js's cache options.

Next.js vs Astro: Full App vs Islands of Interactivity

Astro renders pages to static HTML by default. It ships zero JavaScript unless you ask for it. Mark a component with a client:* directive, like client:visible or client:load, and only that piece gets hydrated in the browser. The rest of the page stays inert HTML.

Next.js, even with React Server Components, still assumes your app is mostly interactive. Client Components hydrate by default wherever you use them. The mental model is "everything might need JavaScript," not "everything is static unless marked."

CMS fit: Astro

A content site is exactly Astro's home turf: mostly text and images, with a comment widget or search box as the one interactive island. Fetching CMS content in Astro looks like this:

---
const res = await fetch('https://api.draftbase.co/delivery/entries?templateId=blogPost');
const { items } = await res.json();
---
<ul>
  {items.map((post) => <li>{post.title}</li>)}
</ul>

Astro also supports React, Vue, Svelte, and Solid components side by side on one page, since each island is independent. That's a real advantage for a team moving off a heavier framework one component at a time. The tradeoff: full client-side routing and app-like state aren't Astro's design center. A dashboard with a dozen linked widgets fights the framework instead of using it.

Is NestJS a Next.js Alternative?

Not really, and it's worth saying that plainly instead of forcing the comparison. NestJS is a backend framework built on Express or Fastify, with Angular-style modules, decorators, and dependency injection. It renders nothing. There's no page, no route component, no image tool.

The confusion usually comes from one setup: a team building a custom API layer in front of a headless CMS. NestJS is a structured way to do that instead of a pile of loose Express routes. In that case, NestJS isn't replacing Next.js. It's sitting behind it. Next.js, or Astro, or React Router, still owns the frontend. NestJS owns request checks, business rules, and any merging of data across sources before the frontend sees it.

CMS fit: NestJS

If your CMS's delivery API already does everything the frontend needs, NestJS is just extra weight: one more service to deploy, patch, and keep warm. It earns its place only when you're merging the CMS with other systems, like inventory or a payments provider, before the frontend gets one combined response.

Comparing the Real Tradeoffs

Framework	Rendering model	CMS fetch pattern	Best fit
Next.js	SSG, ISR, SSR, all per route	fetch in Server Components, cache-tagged	Content sites and interactive apps in one codebase
React Router	Server or client loaders, one model	loader function per route	Apps with account-gated, always-fresh data
Astro	Static HTML, opt-in JS islands	Top-level await fetch in the frontmatter	Content-heavy sites with light interactivity
NestJS	None (backend only)	N/A, sits behind the frontend	Custom API layer merging several data sources

What Most Comparisons Get Wrong

Most "Next.js alternatives" roundups treat this as one decision: pick a framework and rebuild everything. In practice, teams running a headless CMS increasingly mix these tools. Astro handles the marketing site and blog. Next.js handles the logged-in app. A thin NestJS layer merges in billing data if the CMS needs it. None of that requires a full migration off Next.js. It just means picking the right tool per surface, and the "vs" framing in most search results leaves no room for that.

When Should You Actually Switch Off Next.js?

Rarely, and usually for one specific reason, not a general complaint. Switch to Astro if your site is 90% static content, and you're shipping megabytes of unused JavaScript for a handful of interactive widgets. Switch to React Router if you're building an app-like product where every route needs fresh, per-user data, and ISR's caching model gets in the way more than it helps. Add NestJS if you're merging three APIs into one, and a route handler file is turning into an unmanageable pile of fetch calls.

Switching frameworks to fix a caching bug, or because a blog post says another one is faster, is usually the wrong reason. Most Next.js speed complaints trace back to unoptimized images, missing next/font, or over-fetching. Not the framework itself.

What Breaks When You Mix Frameworks on One Domain?

Running Astro for marketing and Next.js for the app sounds clean until routing comes up. Two separate builds means two separate deploys, and a shared header or footer now lives in two codebases unless you extract it into a published component package.

The usual fix is a path split at the edge: /app/* routes to the Next.js deployment, everything else to Astro. Vercel and Netlify both support this with rewrites, so visitors never see the seam. The cost shows up in shared state instead. A logged-in user's session needs to work across both apps, which means a shared auth cookie or token, checked the same way in both places.

Design tokens are the other trap. Two frameworks, two build pipelines, and a color change now needs two pull requests unless the CSS variables live in one shared package both sites import. Skip this step and the marketing site and the app slowly drift apart, one dark-mode fix at a time.

None of this is a reason to avoid mixing frameworks. It's a reason to plan the shared surface (auth, design tokens, navigation) before the first Astro page ships, not after the drift is already visible.

Conclusion

Next.js, React Router, Astro, and NestJS solve different problems. Treating them as one decision misses that. React Router simplifies data fetching into one loader pattern, at the cost of built-in caching. Astro strips JavaScript by default, which fits a content site better than an app. NestJS isn't a frontend alternative at all. It's what sits behind one, when a CMS's API needs merging with something else.

Whichever frontend you pick, the CMS underneath should stay framework-agnostic. Draftbase's delivery API works the same over fetch in Next.js, a React Router loader, or Astro's frontmatter, with the same REST or GraphQL response either way. Start on Hobby for free, no card needed.