Stop Using Next.js for Everything: When Astro, Remix, or Plain Vite Is the Better Choice
TL;DR: Next.js dominates with ~60% usage, but satisfaction has cratered to 55% — a 39-point gap behind Astro. Cloudflare rebuilt 94% of Next.js in one week for $1,100. The framework that's right for your SaaS dashboard is wrong for your marketing site. Here's the decision framework.
📖 Reading time: ~8 minutes | Level: Intermediate–Advanced | Updated: June 2026
The Framework That Won the War Is Losing the Peace
Next.js won. It has 67% enterprise market share, ~60% usage among JavaScript developers, and the deepest ecosystem in the React world. When you type npx create-next-app, you're choosing the default — the thing nobody gets fired for picking.
But here's the number that should make you pause: 55% satisfaction.
According to the State of JavaScript 2025 survey, Next.js satisfaction dropped from 68% to 55% — the steepest decline of any major framework. It generated more negative comments than any other project surveyed. Developer sentiment is 21% positive and 17% negative. The framework itself and its corporate parent are named directly as pain points.
Meanwhile, Astro sits at a 39 percentage point satisfaction lead over Next.js. SvelteKit at 93%. Even React Router v7 (Remix's new identity) outperforms Next.js on satisfaction.
The disconnect is staggering: Next.js has the most users and the unhappiest ones.
Framework Satisfaction — State of JS 2025
SvelteKit ██████████████████░ 93%
Astro █████████████████░░ 90%
Next.js ██████████░░░░░░░░░ 55% ← satisfaction crater
Remix/RRv7 ██████████████░░░░░ 72%
Nuxt ██████████████░░░░░ 71%
This isn't a "Next.js is bad" post. It's a "Next.js is the wrong hammer for most screws" post. Here's when — and why — you should pick something else.
The Complexity Tax: What Developers Are Actually Complaining About
The State of JS 2025 meta-frameworks section reveals the top pain points:
| Rank | Pain Point | Mentions |
|---|---|---|
| #1 | Excessive complexity | 303 |
| #2 | Next.js itself (the framework) | 241 |
| #10 | Lock-in | 70 (+5 positions YoY) |
These aren't complaints about "SSR is hard" or "React is confusing." Developers are calling out Next.js and Vercel by name.
The open letter "Please Fix Next" captures the mood:
"Creeping complexity. Vendor lock-in. Magic hidden behind opaque walls and experimental flags. Each release feels more like a marketing show than a developers' party."
The LogRocket analysis puts it bluntly: Next.js is "developer-friendly in the way a sports car is driver-friendly: powerful and capable, but you'd better know what you're doing."
The core issues:
App Router complexity. Server Components, Client Components,
"use client"boundaries, caching layers, and four different rendering strategies create a steep mental model. The Pages Router was simple; the App Router is not.Vendor lock-in architecture. Features like Image Optimization, ISR, and Edge Middleware work seamlessly on Vercel. Deploy elsewhere and you're fighting the framework. As one developer put it: "I don't want architectural decisions to quietly become billing decisions."
Breaking changes. Major version releases introduce new paradigms that require significant rewrites. The migration from Pages Router to App Router was not a simple upgrade.
Security surface. CVE-2026-23869 hit React Server Components in April 2026, specifically affecting Next.js App Router applications. The complexity of RSC directly expanded the attack surface.
The ViNext Wake-Up Call
On February 24, 2026, Cloudflare dropped a bombshell: one engineer rebuilt 94% of the Next.js API surface in one week, using AI, for $1,100 in API tokens.
The project — vinext — is a Vite plugin that reimplements the Next.js API surface. It reads your existing app/, pages/, and next.config.js files without modification, but swaps the underlying toolchain from Turbopack to Vite.
The performance numbers are striking:
Build Performance — 33-Route App Router App
vinext (Vite 8 / Rolldown) ████████████░░░░ 1.67s (4.4x faster)
Next.js 16 (Turbopack) █████████████████ 7.38s (baseline)
Client Bundle Size (gzipped)
vinext ██████████████░░░░ 72.9 KB (57% smaller)
Next.js █████████████████ 168.9 KB
The project has 1,700+ Vitest tests, 380 Playwright E2E tests, and is already running in production on CIO.gov. It deploys to Cloudflare Workers with a single vinext deploy command.
The significance isn't that vinext will replace Next.js (it's explicitly experimental). It's that the complexity people complain about isn't necessary. A competent engineer with AI assistance proved that 94% of what Next.js does can be done with a simpler, faster, more portable toolchain — in seven days.
The Decision Framework: Which Framework for Which Project
Here's the core insight: there is no best framework. There is only the best framework for your specific project.
When to Choose Astro
Astro is the undisputed champion for content sites. Its zero-JS-by-default philosophy means it ships HTML, not a React application. JavaScript is only loaded for interactive "islands" that explicitly need it.
Real performance numbers (from a standardized e-commerce test app, March 2026):
| Metric | Astro | Next.js | Remix |
|---|---|---|---|
| Lighthouse Score | 99 | 94 | 91 |
| TTFB (static) | 45ms | 120ms | 135ms |
| LCP | 0.8s | 1.4s | 1.6s |
| JS Shipped | 12KB | 87KB | 65KB |
| Full page load (3G) | 1.2s | 2.8s | 2.4s |
That 12KB vs. 87KB isn't a rounding error — it's a fundamentally different architecture.
Astro is the right choice when:
You're building a blog, documentation site, marketing page, or portfolio
SEO and Core Web Vitals are top priorities
You want to mix React, Vue, and Svelte components in the same project
You need static generation at scale (Astro builds 3x faster than Next.js for large sites)
Astro is the wrong choice when:
You're building a highly interactive SPA (dashboards, real-time apps)
You need complex client-side state management across the entire app
You rely heavily on React Server Components
Notable: Cloudflare acquired Astro in January 2026, giving it enterprise-level backing. Astro is no longer a "hobby framework."
When to Choose Remix (React Router v7)
Remix merged into React Router v7, and the combined framework offers the cleanest full-stack React mental model available. Its core philosophy: progressive enhancement through web standards.
Forms work without JavaScript. Links work without JavaScript. The application is usable before the JS bundle loads. When JavaScript does load, everything gets faster and more interactive.
// Remix/React Router v7: A form that works with or without JavaScript
export async function action({ request }) {
const formData = await request.formData();
const email = formData.get("email");
// Validate on the server
if (!email || !email.includes("@")) {
return { error: "Invalid email" };
}
await subscribeToNewsletter(email);
return { success: true };
}
export default function Newsletter() {
const actionData = useActionData();
return (
<Form method="post">
<input type="email" name="email" required />
<button type="submit">Subscribe</button>
{actionData?.error && <p role="alert">{actionData.error}</p>}
{actionData?.success && <p>Subscribed!</p>}
</Form>
);
}
Remix is the right choice when:
Your app is 70% forms and data mutations (admin panels, CRUD apps, multi-step workflows)
You value web standards and want predictable behavior
You need to deploy outside Vercel without fighting the framework
You're building a Shopify storefront (Hydrogen runs on React Router v7)
Remix is the wrong choice when:
You need the full React Server Components model
Your app is primarily static content (Astro is better)
You want the largest ecosystem and hiring pool (Next.js wins here)
When to Choose Plain Vite + React
Sometimes the right answer is no meta-framework at all. If you're building a simple SPA — an internal tool, a prototype, a client-side-only app — you don't need SSR, file-based routing, or server functions.
npm create vite@latest my-app -- --template react-ts
That's it. You get:
Near-instant HMR (Vite's ESM-based dev server)
Zero framework overhead in your bundle
Complete control over your architecture
The freedom to add only what you need
Vite has effectively won the build tool wars. State of JS 2025 shows Vite within 2 points of overtaking webpack in adoption, with a 78-point satisfaction advantage (97% vs 34%). The build tool wars are over. Vite won.
Plain Vite is the right choice when:
You're building a client-side-only SPA
You don't need SSR, SSG, or server functions
You want maximum simplicity and minimum abstraction
You're prototyping or building an internal tool
When Next.js Is Still the Right Answer
Let's be clear: Next.js remains the best choice for many projects. It has:
The largest ecosystem of plugins, examples, and community resources
The deepest integration with React Server Components
Vercel's infrastructure (edge functions, image optimization, analytics)
The biggest hiring pool
Battle-tested at massive scale
Next.js is the right choice when:
You're building a complex SaaS application that benefits from RSC
Your team is already experienced with the App Router
You're all-in on Vercel's platform
You need the largest ecosystem and don't mind the complexity tax
You're building a content-heavy site that also needs significant interactivity (the hybrid case)
Next.js is the wrong choice when:
You're building a mostly-static content site (use Astro)
You're deploying outside Vercel (the lock-in friction is real)
Your team is small and the App Router learning curve is slowing you down
You're building a form-heavy CRUD app (Remix's loader/action model is cleaner)
The TanStack Start Wildcard
TanStack Start — built by Tanner Linsley (TanStack Query, Router, Table) — hit v1.0 in early 2025 and has emerged as the first credible Next.js alternative with a coherent philosophy.
Its pitch: keep the type-safety and explicit control of TanStack Router, add a real server runtime via Nitro (same engine Nuxt uses), and ship without lock-in.
// TanStack Start: Type-safe routing + server functions
// Routes are fully typed — params, search params, loaders, server functions
export const Route = createFileRoute('/products/$productId')({
loader: async ({ params }) => {
// params.productId is typed as string
const product = await db.products.findById(params.productId);
return { product };
},
component: ProductPage,
});
function ProductPage() {
const { product } = Route.useLoaderData();
// product is fully typed — no casting, no generics
return <ProductDetail product={product} />;
}
TanStack Start is the right choice when:
Type-safe routing and search params are core to your UX
You're building data-heavy dashboards or SaaS back-office tools
You want to deploy anywhere without vendor lock-in
Your team already uses TanStack Query and values explicit patterns
TanStack Start is the wrong choice when:
You depend heavily on React Server Components
You're building a content-first marketing site (use Astro)
You have an existing Next.js app that works (don't migrate just to migrate)
You need the largest ecosystem and community resources
Performance: The Numbers That Matter
All benchmarks are from real production measurements, not "hello world" tests:
Content Site Performance — 100-page Site, Same Content, Same Hosting
JavaScript Bundle (KB)
Astro ██░░░░░░░░░░░░░░░░ 12 KB
Remix ██████████░░░░░░░░ 65 KB
Next.js ██████████████░░░░ 85 KB
Largest Contentful Paint (LCP, mobile 4G)
Astro ████████░░░░░░░░░░ 0.8s
Remix ██████████░░░░░░░░ 1.0s
Next.js ████████████░░░░░░ 1.2s
Build Time (100 pages)
Astro ████░░░░░░░░░░░░░░ 20s
Remix ███████░░░░░░░░░░░ 35s
Next.js █████████░░░░░░░░░ 45s
Lighthouse Performance Score
Astro ██████████████████ 99
Remix █████████████████░ 95
Next.js ████████████████░░ 92
For content sites, Astro wins every metric. For interactive apps, the gap narrows — you need that JavaScript anyway. But the baseline overhead difference is real and persistent.
The Bottom Line
The React framework landscape is no longer a one-horse race. Here's the cheat sheet:
| You're Building | Use |
|---|---|
| Blog, docs, marketing site | Astro |
| Form-heavy CRUD, admin panel | Remix / React Router v7 |
| Complex SaaS with RSC | Next.js |
| Data-heavy dashboard, type-safety critical | TanStack Start |
| Simple SPA, no SSR needed | Plain Vite + React |
| E-commerce (Shopify) | React Router v7 (Hydrogen) |
| E-commerce (headless, static products) | Astro |
The pragmatic playbook for most teams:
Keep production on Next.js if it's working. Don't rewrite for the sake of rewriting.
Start the next internal tool or admin dashboard on Remix or TanStack Start. Let lived experience — not Twitter benchmarks — inform broader adoption.
Use Astro for every new content site. The performance gap is too large to ignore.
Watch vinext. If Cloudflare ships a stable version with 94% API coverage, the calculus changes overnight.
The ecosystem is healthier with real competition. Next.js pushed the industry forward with RSC, streaming SSR, and the App Router. Now Astro, Remix, and TanStack Start are pushing back — with simpler architectures, web standards, and genuine deployment freedom.
The right framework isn't the most popular one. It's the one that makes your specific project successful.
→ What's your team using in 2026? Still on Next.js, or have you tried Astro/Remix/TanStack Start? Drop your experience in the comments.
Post Metadata
| Field | Value |
|---|---|
| Word Count | ~2,200 words |
| Reading Time | ~8 minutes |
| Primary Keyword | Next.js vs Astro vs Remix 2026 |
| Secondary Keywords | meta-framework comparison, TanStack Start, Vite, framework decision, State of JS 2025 |
| Target Audience | Intermediate–Advanced frontend developers, tech leads |
| Difficulty | Intermediate |
Suggested Tags: #nextjs #astro #remix #react #webdev #frontend #javascript #tanstack #vite #framework
Suggested Social Caption (LinkedIn/X):
Next.js satisfaction cratered to 55% — a 39-point gap behind Astro. Cloudflare rebuilt 94% of Next.js in one week for $1,100.
The framework that's right for your SaaS dashboard is wrong for your marketing site. Here's the decision framework for 2026: when to use Astro, Remix, TanStack Start, or plain Vite instead of defaulting to Next.js.
🔗 [link]
Sources Researched: