Most ranking guides for 'Next.js vs Remix vs Astro' read like a vendor brochure with no production data behind them. The bejamas piece — currently among the top results for the query — is 1,300 words from May 2025, has zero code examples, zero real benchmarks, no migration guidance, and no version-specific 2026 facts. The framework landscape moved a long way in twelve months. This is the post written from the other side of that movement, with the production numbers to back the recommendations.
Specifically: I run a 91,000-page Astro site (HostList.io) in production, ship Next.js builds for Seahawk Media clients including the recently-launched WordPress Stack Advisor tool, and have evaluated Remix on three client projects since the React Router 7 merger landed. The framework versions covered here are anchored to where they actually are in 2026 — Next.js 16 with the App Router stable, Remix's React Router 7 unification, Astro 5 with Server Islands and Content Layer. The version anchor matters because every shallow comparison post you've read is reasoning from the 2024 versions.
The thesis: pick by content shape, not by framework
Three frameworks, three different optimal use cases, almost zero overlap when you actually look at the brief instead of the spec sheet.
- Astro is the right call when content is the protagonist. Marketing sites, documentation, programmatic SEO at scale, content-heavy sites with light interactivity. The HostList directory at 91,000 pages is the maximum-strength version of this case.
- Next.js is the right call when the application is the protagonist. Authenticated dashboards, ecommerce, real-time features, AI-driven products, anything where the page is mostly a host for dynamic behaviour. The WordPress Stack Advisor is a small-scale version of this case — a Claude API call wrapped in a Next.js Server Action.
- Remix is the right call when the data layer is the protagonist. Forms-heavy enterprise apps, admin tools, anything where progressive enhancement and proper Web Standards form handling matter more than the marketing surface. After the React Router 7 merger, Remix is structurally a Next.js alternative for this specific use case rather than a competitor across the board.
Astro 5 in 2026: what it actually does well, with production numbers
Astro 5 (released late 2024, current as of mid-2026) is the framework most people misjudge because they look at the spec sheet rather than running it at scale. The thing that matters is not the syntax or the component model — it is the rendering architecture: Astro renders zero JavaScript by default, then 'islands' of interactivity hydrate per-component. For content-heavy sites, this is the only framework where the JavaScript bundle actually represents what the page actually needs.
HostList: 91,000 pages on Astro, real numbers
HostList.io runs on Astro 5 with Supabase and Vercel. As of mid-2026 the site has 91,000 published pages across hosting providers, hosting categories, country directories, and educational guides. Production performance: median Lighthouse mobile 92, LCP under 1.2 seconds at the 75th percentile, build time around 18 minutes for a full rebuild. The same site on Next.js with comparable static generation would be a 45-60 minute build at minimum and would ship roughly 5-8x more JavaScript per route.
Astro 5's specific 2026 wins
- Server Islands — render parts of a static page on the server at request time without making the whole page dynamic. Killed the 'static or dynamic' false dichotomy for content sites.
- Content Layer API — replaced Content Collections. Pull content from Supabase, Markdown, MDX, headless CMS, or any custom loader; type-safe at the build step.
- View Transitions API — proper page transitions across navigations without client-side routing overhead.
- Image optimisation pipeline — built-in with sharp, no bolted-on plugin needed. Critical for content-heavy sites.
Where Astro fails
- Authenticated dashboards. Astro's Server Islands can do auth-aware rendering, but the patterns are less mature than Next.js Server Components with auth.
- Real-time features. Possible with Astro + Supabase Realtime, but Next.js makes this easier.
- Complex form workflows with progressive enhancement. Remix is purpose-built for this. Astro is not.
- Big-team React-only shops. Astro lets you mix React, Vue, Svelte, Solid, but most teams treat that flexibility as overhead.
Next.js 16 in 2026: the right call when application logic is the brief
Next.js 16 (released late 2025, current as of mid-2026) consolidated the App Router as the single recommended pattern, deprecated the Pages Router for new projects, and made Server Actions the default form handling primitive. The framework is more opinionated than it was in 2024, which is the right move — having two routers and four data-fetching patterns was killing teams in production.
Stack Advisor production example
The WordPress Stack Advisor is a working Next.js 16 application: Server Action receives a URL, fetches the target site, runs CMS detection through 30 plugin fingerprints, calls Claude Sonnet 4.5 with prompt-cached system prompt, returns a tailored stack recommendation. The whole tool is roughly 530 lines of TypeScript, deploys to Vercel as a single Edge Function, and runs at $0.02 per analysis with prompt caching enabled. This is the shape of brief Next.js makes easy: a couple of dynamic routes, a Server Action that does real work, an external API call.
Next.js 16's specific 2026 wins
- App Router stable and the recommended pattern. Server Components are the default rendering model. Client Components are explicit opt-in.
- Server Actions for form handling. No API route boilerplate for most CRUD work.
- On-demand revalidation via revalidatePath / revalidateTag. ISR works without the Next.js 13 caveats.
- Turbopack now default in dev. Cold starts in production builds are still slower than Astro but the dev loop is finally fast.
- Vercel HIPAA BAA at $350/month on Pro since September 2025. This is the change that opened up Next.js for healthcare without the $45K/year Enterprise contract — the kind of unlock that changes which projects ship on Next.js at all.
Where Next.js fails
- Content sites at 50,000+ pages. Build times become punishing. The page-to-route ratio gets ugly.
- Static-output marketing sites. Possible but you ship 5-8x more JavaScript than Astro for the same outcome.
- Forms-heavy admin apps with serious progressive enhancement requirements. Server Actions are good but Remix's loader/action model is purpose-built.
- Self-hosted-only deployments. Possible (Docker, Cloudflare Workers, AWS), but the friction is real. Astro and Remix self-host more cleanly.
Remix in 2026: the React Router 7 merger and what it means
In late 2024 the Remix team announced Remix would merge into React Router 7, with Remix v3 being the final standalone Remix release. As of mid-2026, the team is shipping under the React Router 7 brand with the Remix-style loader/action model intact. For the purposes of this comparison, 'Remix' means 'React Router 7 framework mode' — the framework formerly known as Remix, now operating under a different name with the same architecture.
What Remix / React Router 7 still does best
- Form handling with proper progressive enhancement. The loader/action model is the cleanest implementation in any React framework.
- Web Standards alignment. Remix uses native Request and Response objects rather than custom abstractions.
- Nested routing with data co-location. Each route handles its own data, and routes nest cleanly. Excellent for admin apps with many sub-screens.
- Self-hosted deployments. Runs on any Node.js, Cloudflare Workers, Bun, or Deno runtime without major caveats.
Where Remix is structurally weaker than Next.js in 2026
- Smaller ecosystem. Plugins, deployment platforms, and community examples skew Next.js by 5-10x.
- Vercel BAA does not cover Remix specifically. If you want HIPAA on Remix, you self-host on AWS with their BAA, which is more work.
- AI / Edge runtime support is more manual. Next.js Edge Functions are first-class; Remix relies on the underlying runtime.
- Marketing-site SEO patterns are less documented. The framework optimises for app-like behaviour, not content-heavy sites.
The actual comparison table — anchored to 2026 versions
Bejamas's comparison table has 11 rows. Theirs is fine for high-level scanning. This is the version with production-grade numbers and 2026-specific facts.
Architecture
- Astro 5: islands architecture. Zero-JS by default, hydrates components on demand. Multi-framework support (React, Vue, Svelte, Solid).
- Next.js 16: React Server Components by default. App Router with Server Actions. Single-framework (React only).
- Remix / RR7: Loader-action data flow on Web Standards. Server-rendered React with progressive enhancement. Single-framework (React only).
Default JavaScript bundle for a marketing homepage
- Astro 5: ~5-15KB if no client islands; up to ~80KB with React islands. Often genuinely zero.
- Next.js 16: ~120-180KB on a vanilla App Router page. Server Components reduce this versus Pages Router but client framework is still shipped.
- Remix / RR7: ~140-200KB on a default page with progressive enhancement enabled.
These numbers are for an empty homepage with one heading and one paragraph. Real sites trend higher. The Astro / Next.js delta typically grows on content-heavy routes; the Astro / Remix delta is roughly stable.
Build time for a 5,000-page static site
- Astro 5: 4-7 minutes on a Vercel build runner with image optimisation.
- Next.js 16: 12-20 minutes for the same content with App Router and ISR. Static-only output narrower this gap but Next.js was not designed for this.
- Remix / RR7: 8-15 minutes. Better than Next.js for static, worse than Astro.
HIPAA / regulated industries support
- Astro on Vercel: Pro BAA add-on at $350/month covers Vercel hosting; Astro itself has no specific HIPAA story (it is a build tool, not a runtime).
- Next.js on Vercel: same Pro BAA $350/month covers Next.js Server Components, Server Actions, ISR. The most mature healthcare-Next.js story.
- Remix / RR7 on Vercel: same Vercel Pro BAA applies but Remix on Vercel is less common in healthcare. Self-host on AWS HIPAA-eligible infrastructure is the more typical path.
Deployment platforms
- Astro: Vercel, Netlify, Cloudflare Pages, GitHub Pages, custom Node, Deno, Bun. Genuinely platform-agnostic.
- Next.js: Vercel is the obvious answer; Cloudflare Workers (with adapter), AWS (custom), Netlify (with adapter). Self-hosting works but is less polished.
- Remix / RR7: Vercel, Cloudflare Workers, Netlify, Fly.io, Railway, custom Node, Bun, Deno. Genuinely runtime-agnostic by design.
Ecosystem and hiring
- Next.js: largest by 5-10x. Most React developers default to Next.js for new projects.
- Astro: growing, but the talent pool is smaller. Most Astro developers learn it on the job rather than arriving with experience.
- Remix / RR7: smaller still. Specialised but high-quality community.
Decision tree: which one for which brief
Is your site primarily content with light interactivity?
Astro 5. If the site is marketing pages, documentation, blog, programmatic SEO at any scale, or any 'mostly static, occasional dynamic' shape — Astro is the right call. The Server Islands feature in Astro 5 specifically covers cases where static pages need a small dynamic widget, without escalating the whole site to dynamic rendering.
Is your site primarily an authenticated application?
Next.js 16. Dashboards, SaaS apps, ecommerce checkouts, real-time features, AI products, anything where the page is a host for application logic. The Server Components plus Server Actions model is the most ergonomic, the largest ecosystem, and on Vercel the easiest to deploy. If you also need HIPAA, the Vercel Pro BAA at $350/month is the unlock.
Is your app forms-heavy with serious progressive-enhancement requirements?
Remix / React Router 7. Admin tools, internal CRUD apps, data-entry workflows, anything where the form handling is the product. The loader/action model on Web Standards is genuinely cleaner than Next.js Server Actions for these specific shapes. The trade-off is the smaller ecosystem.
Is the site a hybrid — content with a small authenticated area?
Astro for the public site, Next.js as a separate app on /app or app.yourdomain.com for the authenticated area. Two frameworks, two deployment targets, both calling the same Supabase backend. This is what the WordPress Stack Advisor architecture would look like at scale: Astro for the marketing site, Next.js for the tool itself. The split scales better than trying to make one framework do both ends of the brief.
Is the brief 'we already have Next.js, should we switch?'
Mostly: stay on Next.js. The migration cost rarely pays off unless the specific issue is build time on a content site that has crossed 30,000 pages. For application-shaped briefs, Next.js 16's App Router is good enough that switching to Remix or Astro for marginal wins is rarely worth the lost ecosystem.
Migration paths between the three
Next.js to Astro (for content-heavy sites that hit build time pain)
Realistic 4 to 8 weeks for a 5,000-page site. The schema migrates cleanly if you are using a headless CMS; the React components mostly port over with minor adjustments because Astro accepts React components as islands. The hard parts are the routing patterns (file-based but slightly different conventions) and the data-fetching model (Astro fetches at build, not at request).
Astro to Next.js (for content sites that grew application requirements)
Harder than the reverse. Astro's island model does not map cleanly to Next.js's component model. Most migrations end up rebuilding the routing layer from scratch in Next.js while keeping the components mostly intact. Realistic 6 to 10 weeks for a similar-sized site.
Remix / RR7 to Next.js (most common Remix migration in 2026)
Cleaner than expected because both frameworks are now React-Server-Components-shaped. The loader/action model maps reasonably well to App Router patterns. The hard parts are the routing convention (Remix's nested folder structure versus Next.js's app directory) and the deployment target. 4 to 8 weeks for a typical-sized app.
Cost economics for a typical project (12-month TCO)
Anchored to 2026 prices for a hypothetical 5,000-page content site with a small authenticated area, 100K monthly visitors, 5-person editor team.
- Astro on Vercel: Pro plan $20/seat × 5 = $100/month. Image CDN included. Build minutes within Pro tier. Annual: ~$1,200 platform layer.
- Next.js on Vercel: same Pro plan, but build minutes typically run higher and image optimisation eats more bandwidth. Annual: ~$1,500-2,000 platform layer for the same scale.
- Remix / RR7 on Cloudflare Workers: Workers Paid $5/month plus bandwidth. Annual: ~$200-500 platform layer (cheapest of the three at this scale).
- Plus database: Supabase Pro $25/month (~$300/year) on top of any of these.
At smaller scale (under 1,000 pages, under 10K monthly visitors), all three frameworks fit comfortably in a $0-50/month budget on free or Pro tiers. The cost gap is real only at meaningful traffic and content scale.
FAQ
Is Next.js better than Remix in 2026?
For most use cases, yes — Next.js has the larger ecosystem, the more mature App Router pattern, and the easier Vercel deployment story. Remix wins specifically for forms-heavy apps with progressive enhancement requirements where the loader/action model adds real value. The Remix-to-React-Router-7 merger has slightly muddled the messaging, but the framework architecture is the same and the use case is the same.
Should I use Astro for a SaaS application?
Generally no. Astro is optimised for content-heavy, mostly-static sites. SaaS apps are application-shaped — authenticated dashboards, real-time data, complex workflows — and Next.js or Remix is the better fit. The exception: if your SaaS has a large marketing site plus a small in-app dashboard, Astro for the marketing site and Next.js for the app is a strong split.
Can I use Astro and Next.js together?
Yes. The hybrid architecture — Astro for the public marketing site, Next.js for the authenticated app — is increasingly common in 2026. Both can call the same Supabase or headless CMS backend. The split scales better than trying to make one framework do both ends of a hybrid brief. The trade-off is the dual-deployment overhead.
Why are Astro builds so much faster than Next.js?
Astro renders to static HTML by default with no React framework overhead. Next.js renders React Server Components, which are lighter than client components but still go through the React rendering pipeline. For 5,000 mostly-static pages, Astro generates roughly 5,000 HTML files; Next.js generates 5,000 HTML files plus an RSC payload per route plus client framework code. The former is fundamentally less work.
Is the Remix to React Router 7 merger a problem?
Not for ongoing projects. Remix v3 is the final standalone Remix release and continues to be supported. New projects should start on React Router 7 framework mode, which has the same loader/action model. The change is mostly branding and packaging; the architecture is unchanged. The merger has caused some confusion in framework-comparison content (including the bejamas piece this post counters) but the practical decision-making is the same.
Which framework is best for SEO?
All three can produce SEO-optimised output, but the ergonomics differ. Astro is the easiest because the default output is static HTML with minimal JavaScript — search engines and AI crawlers see exactly what users see, no rendering tricks needed. Next.js requires the App Router with Server Components for the same outcome (which is the default in 2026). Remix produces server-rendered HTML by default but the marketing-site SEO patterns are less documented than for the other two.
Where the bejamas piece falls short — for the record
To be fair to bejamas, their post is competent and ranks for valid reasons — they are a long-established Jamstack agency with strong domain authority. The piece is shallow rather than wrong. The specific gaps:
- Written in May 2025, before Astro 5, before Next.js 16, before the React Router 7 merger announcement. The framework versions are 12+ months stale.
- No code examples. Every framework comparison without a single file is structurally incomplete.
- No real production numbers. The post claims 'fast' and 'scalable' without anchoring to actual Lighthouse scores, build times, or bundle sizes.
- No FAQ schema. Limits AEO and AI Overview citation.
- No migration paths. Most readers searching this query are evaluating a switch, not a fresh start. The piece doesn't address this.
- No cost comparison beyond 'budget-friendly'. For a business decision post, this is the most surprising gap.
Related reading
Sanity in 2026: where it actually wins — the matching CMS-layer comparison for a Next.js or Astro front end.
Next.js + headless CMS in 2026: which one for which brief — the broader CMS choice once you have picked Next.js as the framework.
Headless WordPress with Astro: a working setup — if your framework choice involves WordPress as the editorial back end.
WordPress to Next.js migration without losing rankings — the SEO transport playbook when the framework choice involves a migration.
WordPress Stack Advisor — paste your URL and get a tailored stack recommendation. Useful if you are weighing Next.js vs Astro vs Remix for a specific site.
The framework choice is rarely the bottleneck. The bottleneck is the team's ability to ship in whichever framework you pick. Pick by fit, train accordingly, ship the version your editorial and engineering teams can both live with.
Book a 30-minute framework pick call — describe the brief, the team, the timeline, the integrations. Walk away with a Next.js / Remix / Astro decision that survives both the engineering review and the editorial onboarding.