Short answer: for a content-heavy marketing site, Astro usually wins; for a highly interactive, app-like product, Next.js or React Router; for an estate that mixes both, the honest answer depends on your content model, your team’s skills, and where you host. At Bejamas, we recommend the framework that fits the client’s estate — not the one we’d prefer to build with — and sometimes that recommendation is to stay where you are.
First, what changed: Remix is now React Router
This article originally compared Next.js, Remix, and Astro in late 2024. Weeks later, the Remix team merged Remix into React Router v7: everything Remix offered — server rendering, data loading, the deployment flexibility — now lives in React Router’s “framework mode.” If you run a Remix v2 application today, the upgrade to React Router v7 is designed to be non-breaking, and it’s the officially recommended path.
Two clarifications, because the naming still confuses people:
- React Router v7 is the Remix successor. Same team, same ideas, new name. Your Remix investment carries over.
- “Remix 3” is not Remix v2’s next version. It’s a separate project that breaks from React entirely, with its own component model and no migration path from Remix v2. As of mid-2026 it is still in beta, and not something to plan a business website around.
So the 2026 comparison is really Next.js vs. React Router vs. Astro. Here’s how they stack up — from a buyer’s point of view, not a developer’s.
1. Next.js: The Default for Teams Deep in the React and Vercel Ecosystem
Next.js remains the most widely adopted React framework. Version 16 (late 2025) made the App Router and React Server Components the settled, mature way to build, made the faster Turbopack bundler the default, and replaced implicit caching “magic” with an explicit model — a long-standing source of production surprises. Brands like Nike, Spotify, and TikTok run on it.
Business Advantages:
-
One framework for static and dynamic: Marketing pages, personalization, e-commerce, and application features can live in one codebase — useful when your site is really several kinds of site.
-
The largest hiring pool and ecosystem: More agencies, developers, integrations, and CMS starter kits target Next.js than any other option here. That lowers key-person risk over a multi-year ownership window.
-
Editor-friendly workflows: Real-time preview integrations with modern headless CMSs are mature, so marketing teams can see changes before publishing.
Considerations:
Next.js is the most complex of the three, and that complexity is paid for in developer time. For a site that is mostly content, you’re carrying application machinery you don’t need.
Popularity also does a lot of quiet work in Next.js decisions — “everyone uses it” reads as “it must be the safe choice.” The criticism worth hearing before you commit clusters around three points.
First, the complexity is real, and it’s acknowledged from the inside. The sharpest version of this critique comes not from a competitor but from Lee Robinson, who spent five years leading Next.js developer experience at Vercel — responding to a developer asking why their site got slower on the App Router:
Hi. I have thoughts. The short answer is that the App Router is easy, but not simple. It's easy to get started, but complexity ramps fast. I've said previously that if you don't need streaming, then the App Router might not be a good fit. Here's a random list of places where complexity ramps: 1. What React Transitions are and how the Next.js router uses them 2. How streaming rendering works and why Next.js APIs are designed around them (e.g. generateMetadata) 3. How dynamic rendering affects different prefetching configurations 4. What the RSC payload is and how to optimize it (e.g. you tried to pass a massive object over the network boundary) 5. Why Server Actions are unguessable and encrypted URL endpoints 6. Why 'use client' is actually a bundler feature (read Dan's blog¹) 7. That reading searchParams makes your page dynamically rendered And there's more. The Next.js Conf keynote² last year did a pretty good job of explaining where there was essential complexity vs accidental complexity. And I do think 'use cache' and other improvements are trending in the right direction. But there's a broader question you gotta step back and ask yourself which is whether Next.js is even the right tool for the job? Many times the answer will be yes (hell, I'm building a Next.js app right now) but also many times it's no. Next.js became a Swiss Army knife. Sometimes you just need a really sharp, single purpose knife. ¹: overreacted.io/why-does-rsc-integrate-with-a-bundler ²: youtube.com/watch?v=19g66ezsKAg
Read 39 replies
That complexity shows up in the annual State of React survey, where Server Components rank among the most painful parts of the ecosystem, and it costs real money: it is paid for in senior developer time, on a site that may mostly be content.
Second, the field data is unflattering for content sites. In Astro’s analysis of public HTTP Archive and Chrome UX Report data, only about 30% of real-world Next.js sites pass Core Web Vitals — behind WordPress (48%) and roughly half of Astro’s 66%. Framework choice doesn’t doom a site (well-built Next.js sites pass fine), but the aggregate says the easy path in Next.js is not the fast path.
Share of real-world sites with good Core Web Vitals, from Astro's analysis of HTTP Archive and Chrome UX Report field data (astro.build).
Third, hosting portability. Next.js runs best on Vercel; self-hosting works, but replicating Vercel’s caching, image optimization, and edge behavior elsewhere is real engineering work — enough that an entire open-source project, OpenNext, exists to do it, with Cloudflare joining as a maintainer to address what its creators plainly call a vendor lock-in problem.
None of this makes Next.js a bad choice — it makes it a choice, not a default. Pick it for the reasons above (mixed content-and-app estates, React hiring pool), price in the complexity and the hosting home, and don’t let popularity stand in for the evaluation.
Best For:
Organizations building content and product surfaces in one stack, with React skills in-house or a partner who has them.
2. React Router (formerly Remix): For App-Like Products, Anywhere You Want to Host
React Router v7 in framework mode is what Remix became: server rendering, route-level data loading, and progressive enhancement built on web standards. Backed by Shopify, it powers heavily interactive, data-driven surfaces — Shopify’s own storefront tooling among them.
Business Advantages:
-
Built for interactivity: Dashboards, configurators, booking flows, account areas — anything where users act on live data is where this framework is strongest.
-
Deployment independence: React Router has no preferred cloud. It runs the same on AWS, Cloudflare, your own infrastructure, or a hosting platform of your choice — a real advantage when governance or existing contracts dictate where things run.
-
A protected investment: The Remix → React Router transition was handled as a compatible upgrade, not a rewrite. Teams on Remix v2 did not lose their codebase — a decent signal about how the maintainers treat breaking change.
Considerations:
It’s a smaller ecosystem than Next.js — fewer prebuilt CMS integrations, fewer developers who know it deeply. And for a mostly-static marketing estate it’s the wrong shape: it assumes a server answering requests, where Astro would pre-render almost everything.
Best For:
Product-led companies and interactive platforms where the “website” behaves like an application — especially where hosting flexibility is a hard requirement.
3. Astro: The Content-Site Specialist That Closed Its Old Gaps
Astro ships pages as plain HTML and loads JavaScript only where a component genuinely needs it — which is why content-heavy sites on Astro tend to be fast without heroics. Astro 6 (March 2026) matured the two features that removed its historical limits: the content layer, which treats any source — markdown, headless CMS, API — as one typed content system, and server islands, which let a static page include server-rendered dynamic sections (pricing, stock, personalization) without giving up static delivery. IKEA, Porsche, and Cloudflare’s developer docs run on it.
Business Advantages:
-
Performance as the default: Less JavaScript shipped means faster pages, which supports SEO and conversion — particularly on large sites where per-page optimization doesn’t scale.
-
Lower running costs: Mostly-static output is cheap to host and cache, and there’s less infrastructure to operate and secure.
-
Framework-agnostic components: Astro renders React, Vue, or Svelte components side by side — useful when consolidating brands or teams with mixed front-end histories onto one platform.
Considerations:
Server islands cover “mostly static, partly dynamic” well, but a genuinely app-like product — heavy client-side state, complex authenticated flows — is still better served by Next.js or React Router.
Best For:
Content-rich marketing estates: multi-brand sites, documentation, publications — anywhere publishing volume is high and interactivity is targeted rather than everywhere.
Comparison Table: Next.js vs. React Router vs. Astro
| Feature | vsNext.js | vsReact Router (formerly Remix) | vsAstro |
|---|---|---|---|
| Primary Use Case | Mixed content + application surfaces in one stack | Interactive, data-driven applications | Content-rich, fast-loading websites |
| Rendering Model | Static, server, and streaming with React Server Components; explicit caching | Server rendering with route-level data loading; static pre-rendering per route | Static-first with server islands for dynamic sections |
| JavaScript Shipped | Full React application, with optimization options | Full React application, progressively enhanced | Minimal by default; loads only where needed |
| UI Frameworks | React | React | React, Vue, Svelte, and others side by side |
| Hosting | Everywhere, but newest features land on Vercel first | Cloud-agnostic by design | Any static host or server runtime |
| Ecosystem & Hiring | Largest of the three | Solid, Shopify-backed, smaller than Next.js | Growing fast, strong CMS integrations |
| Remix v2 Codebase | Rewrite required | Designed as a non-breaking upgrade | Rewrite required |
| Watch Out For | Complexity you may not need on a content site | Wrong shape for mostly-static estates | Not built for app-like products |
More detail on each platform: our stack library.
Which Framework Should You Choose?
-
A multi-brand or multi-market marketing estate — many sites, heavy publishing, targeted interactivity: Astro, usually paired with a headless CMS as part of a composable architecture.
-
An app-like product — logged-in experiences, live data, complex workflows: Next.js if you want the biggest ecosystem and Vercel fits your governance; React Router if hosting independence matters or you’re already on Remix.
-
A mixed estate — a large content site with real application features: either Next.js for everything, or Astro for the content estate with the application kept separate. Which is right depends on your team and content model, and it’s worth an audit before the decision, not after.
-
Already on Remix v2 or an older Next.js version, and the site works? Upgrading in place — Remix v2 to React Router v7, or Pages Router to App Router on your own schedule — is often the better business decision than replatforming. Staying where you are is a valid answer.
Need Help Deciding?
If you’re weighing which framework fits your estate, talk to us. We’ll assess what you have — content model, team, hosting, governance — and recommend the stack that fits, with the trade-offs written down.
Find the Right Framework for Your Estate
The right framework depends on what you’re running today and what your team can own tomorrow. We work across Next.js, React Router, Astro, and the wider modern stack — and we recommend the one that fits your business case, including when that means staying put.
