Next.js owns 67% market share but satisfaction is tanking. Astro is surging. Remix merged into React Router. Nobody is winning.
Get new posts delivered to your inbox. No spam, unsubscribe anytime.
Next.js owns 67% of the enterprise meta-framework market. It's the default. The thing you pick when you don't want to justify your choice in a meeting. And yet, according to the State of JS 2025 survey, developer satisfaction with Next.js dropped from 68% to 55% — the largest drop of any major framework. Meanwhile, Astro, which most teams hadn't heard of two years ago, now has the highest satisfaction rating among all meta-frameworks. A full 39 points above Next.js.
Something weird is happening. The most popular framework is also the one developers are most frustrated with. And the framework developers love most barely registers in enterprise adoption. That gap — between what companies deploy and what developers actually enjoy using — is the entire story of the 2026 framework wars.
Spoiler: nobody is winning. Because they're not actually fighting the same war.
Let's get the data on the table before the opinions start flying.
The State of JS 2025 survey tells a complicated story. Next.js sits at 60-70% usage adoption — dominant by any measure. But that 55% satisfaction score is brutal. It means roughly half the people using Next.js would rather be using something else. They're stuck, not happy.
Astro's trajectory is described as a "dramatic transformation from near obscurity to serious contender." It went from a niche static-site tool to the framework with the highest developer satisfaction in the entire meta-framework category. That's not a fluke. That's a product doing something fundamentally right.
Remix lands somewhere in the middle — favored for its simplified data handling and fast dynamic rendering, but it doesn't dominate market share. And its identity crisis (more on that soon) makes the numbers hard to interpret.
The Stack Overflow 2025 survey backs this up from a different angle. Node.js is used by 48.7% of developers, React.js by 44.7%. Both Next.js and Astro are highlighted as gaining traction. But traction and dominance are very different things.
Here's what most comparison articles get wrong: they line up these three frameworks in a feature matrix and declare a winner. That's like comparing a pickup truck, a sports car, and a bicycle. They all have wheels. They solve completely different problems.
Next.js 16 shipped with genuinely impressive improvements. I'm not going to pretend otherwise. The engineering is real.
The headline feature is the "use cache" directive — opt-in caching that's explicit and flexible. This matters because Next.js caching has been a source of developer rage for two years. The old implicit caching behavior broke people's apps in subtle ways. The new approach says: nothing is cached unless you tell it to be. That's a massive improvement in developer experience.
Performance numbers are strong. RSC payload deserialization is up to 350% faster. HTML rendering is 25-60% faster depending on payload size. These aren't marketing numbers — they're measurable in production apps.
Then there's Turbopack, now stable and the default bundler. The benchmarks against Vite tell an interesting story:
| Metric | Turbopack | Vite | Webpack (legacy) |
|---|---|---|---|
| Cold start | 3-5s | Less than 1s | 8-15s |
| HMR (small project) | 35ms | ~120ms | 300-500ms |
| HMR (large project) | 35ms consistent | 300-400ms drift | Unusable |
| Build time improvement | 2-5x faster than Webpack | — | Baseline |
Vite wins cold start by a mile. But Turbopack's consistency on large codebases is remarkable — 35ms HMR regardless of project size, while Vite degrades as the project grows. For enterprise teams with 500+ component projects, that consistency matters more than raw cold-start speed.
The React Compiler is also stable now — auto-memoization with zero manual changes. No more useMemo and useCallback sprinkled everywhere. The compiler figures it out. This alone removes an entire category of performance bugs that junior devs introduce and senior devs spend hours debugging.
Here's the thing. All of this is great engineering solving problems that Next.js itself created.
React Server Components are powerful. They're also a fundamentally different mental model than what most React developers learned. You now need to think about which components run on the server, which run on the client, how data flows between them, when to use "use client" vs "use server", and how caching interacts with all of it.
The "use cache" directive is a fix for a caching system that shouldn't have been implicit in the first place. The React Compiler is a fix for a hooks API that was too easy to misuse. Turbopack is a fix for Webpack being too slow.
Next.js 16 is a better version of a framework that keeps accumulating surface area. Every release adds concepts. Server Actions. Parallel Routes. Intercepting Routes. Partial Prerendering. The App Router vs Pages Router split that still hasn't fully resolved. The source for Next.js 16 reads like a changelog for three different frameworks stitched together.
I've talked to senior engineers at companies running Next.js in production. The pattern I hear is consistent: "It does everything we need, and we spend 30% of our time figuring out how."
That 55% satisfaction score? This is why.
Remix's story in 2026 is one of the strangest in open-source history.
Shopify acquired the Remix team in 2022. That alone raised eyebrows. A commerce company buying a web framework? But the bigger shock came later: the Remix team decided to merge Remix into React Router v7. Not as a separate product built on top of React Router. Literally merged. Remix's features became React Router features. The Remix brand effectively died.
Think about that. A framework with genuine developer love — people chose Remix because of its web-standards-first approach, its loader/action pattern, its rejection of unnecessary complexity — got absorbed into a routing library. The philosophy survived. The brand didn't.
New Shopify CLI apps now use React Router v7 instead of Remix. If you go to the Remix documentation, it redirects you to React Router docs. The framework that was supposed to be the anti-Next.js became a feature set inside a dependency.
Then came the Remix 3 announcement, pushing "agentic workflow" and AI-first development. This is... a pivot, to put it generously.
The original Remix pitch was beautiful in its simplicity: web standards, progressive enhancement, nested routes with colocated data loading. It was the framework for developers who thought React had gotten too complicated. It was the framework that said "the platform is good enough, stop fighting it."
Now it's an "agentic workflow" framework. I don't even know what that means, and I suspect the Remix team is still figuring it out too.
Honestly? The React Router v7 approach is solid engineering. If you're building a React app that needs dynamic server rendering, the loader/action pattern is still one of the best abstractions out there. It's clean, it's predictable, it follows web standards.
But Remix as a brand is in limbo. It's not dead — the team is talented and Shopify's backing is real. But it's hard to recommend "Remix" to a team when the answer is actually "use React Router v7 with framework mode enabled." That's not a pitch. That's a configuration instruction.
The framework war requires a clear identity. Remix's identity is currently: we're part of React Router, we're owned by Shopify, and we're pivoting to AI. That's three things at once, and none of them is a compelling story for a team choosing their next stack.
Astro's rise has been the most interesting storyline in web development since React itself.
The core idea is radical: ship zero JavaScript by default. Every page is static HTML unless you explicitly opt in to client-side interactivity. In a world where Next.js's "hello world" ships roughly 85-100KB gzipped of JavaScript, Astro ships literally zero.
The performance implications are massive. LCP (Largest Contentful Paint) is 40-70% better than Next.js for content sites. Not 5% better. Not 10% better. Forty to seventy percent. That's the difference between a page that feels instant and a page that makes you wonder if something broke.
The secret sauce is islands architecture. Instead of hydrating the entire page (like Next.js does with RSC), Astro treats interactive components as isolated islands in a sea of static HTML. Each island hydrates independently. A comment widget loads its JavaScript without affecting the navigation bar or the article content.
This sounds simple. It is simple. And that simplicity is Astro's biggest advantage. You don't need to understand server components vs client components. You don't need a mental model for streaming SSR. You write components, mark the interactive ones, and Astro handles the rest.
The "bring your own framework" approach is genuinely wild. You can use React, Vue, Svelte, and Lit components in the same project. On the same page. This isn't a theoretical feature — teams actually use it. I've seen projects where the marketing team writes Svelte components and the product team writes React components, and they coexist in a single Astro site.
In January 2026, Cloudflare acquired the Astro team. The framework stays MIT-licensed open source. But now it has the backing of one of the largest edge computing platforms on the planet.
This is a different kind of acquisition than Shopify buying Remix. Cloudflare's business model is edge infrastructure. Astro generates static HTML that deploys perfectly to edge networks. The alignment is natural. Cloudflare wants more sites on their edge. Astro makes sites that are ideal for edge deployment. Both sides win.
Adoption is doubling every year. Unilever, Visa, and NBC News are using it in production. These aren't side projects. These are major organizations choosing Astro over Next.js for their content properties.
But let's be honest about what Astro can't do.
Try building a complex dashboard with real-time data in Astro. Try building a collaborative document editor. Try building a SaaS app with dozens of interactive forms, drag-and-drop interfaces, and WebSocket connections.
You can technically do it. Islands can be as complex as you want. But at some point, when every island is interactive and they need to share state, you're fighting the architecture instead of benefiting from it. Astro was designed for content-first sites. When you push it beyond that, you lose the zero-JS advantage that made it compelling in the first place.
This isn't a criticism. It's a boundary condition. Every good tool has them.
Here's the comparison table that actually matters. Not "which has more GitHub stars" but "which one solves your specific problem."
| Metric | Next.js 16 | Remix / React Router v7 | Astro |
|---|---|---|---|
| Initial JS bundle (hello world) | 85-100KB gzipped | 50-70KB gzipped | 0KB |
| LCP (content site) | Baseline | ~10% better | 40-70% better |
| HMR (Turbopack/Vite) | 35ms consistent | 120ms (Vite) | 120ms (Vite) |
| Cold start (dev server) | 3-5s | Less than 1s | Less than 1s |
| Build time (large site) | Fast (Turbopack) | Fast (Vite) | Very fast (Vite) |
| Factor | Next.js 16 | Remix / React Router v7 | Astro |
|---|---|---|---|
| Learning curve | Steep (RSC, caching, etc.) | Moderate | Gentle |
| Mental model complexity | High | Medium | Low |
| Documentation quality | Extensive but scattered | Good but in transition | Excellent |
| Community size | Massive | Small but devoted | Growing fast |
| Satisfaction (State of JS) | 55% | Data mixed with RR | Highest in category |
| Scenario | Best Choice | Why |
|---|---|---|
| Marketing / content site | Astro | Zero JS, best LCP, islands for interactivity |
| Documentation site | Astro | Static by default, fast builds |
| E-commerce storefront | Next.js or Astro | Depends on interactivity needs |
| SaaS dashboard | Next.js | Full React, complex state management |
| Real-time collaborative app | Next.js | WebSockets, complex client state |
| Blog / portfolio | Astro | Overkill to ship React for a blog |
| Shopify app | React Router v7 | Shopify CLI default, good integration |
| Form-heavy CRUD app | Remix / React Router v7 | Loaders/actions are ideal for this |
| Enterprise internal tool | Next.js | Ecosystem, hiring pool, Vercel support |
| Factor | Next.js 16 | Remix / React Router v7 | Astro |
|---|---|---|---|
| Corporate backer | Vercel | Shopify | Cloudflare |
| Enterprise market share | 67% | Small | Growing |
| Framework maturity | Very mature | Transitioning | Maturing fast |
| Lock-in risk | Moderate (Vercel-optimized) | Low | Low |
| Hiring pool | Large | Small | Small but growing |
I've read dozens of "Next.js vs Remix vs Astro" posts while researching this piece. Almost all of them make the same mistake: they treat these frameworks as direct competitors.
They're not.
Next.js is a full-stack React application framework. It's for teams building complex, interactive web applications where React's component model and state management are genuine requirements. Dashboards. SaaS products. E-commerce platforms with heavy personalization. Internal tools.
Astro is a content-first framework that happens to support interactivity when you need it. It's for sites where the primary purpose is delivering information — text, images, structured content — and interactivity is secondary. Marketing sites. Blogs. Documentation. News sites.
Remix (React Router v7) is a server-first React framework focused on data mutations and progressive enhancement. It's for apps where forms, data loading, and server rendering are the core workflow. CRUD apps. Form-heavy interfaces. Apps where progressive enhancement and web standards matter.
Comparing them head-to-head on features is like reviewing a truck, a Tesla, and a bicycle on their towing capacity. The bicycle doesn't tow. It was never designed to tow. That doesn't make it worse. It makes it a bicycle.
The real question isn't "which framework is best?" It's "what are you building?"
Here's my practical guide for choosing in 2026. Be honest about what you're actually building, not what you might build someday.
Use Next.js when:
Use Astro when:
Use React Router v7 (Remix) when:
Don't use any of these when:
I've spent three weeks researching this article. I've read the surveys, the benchmarks, the corporate blog posts, the acquisition announcements, and too many Twitter threads. Here's what I actually believe.
The framework war is fake.
Not fake as in "the frameworks don't compete for mindshare." They do. Not fake as in "the choice doesn't matter." It matters a lot. Fake as in: the framing of a three-way war where one framework wins and the others lose is fundamentally wrong.
Next.js won the application framework market. It has 67% enterprise share. That fight is over. The question for Next.js isn't "will it win?" but "will it keep developers happy while it wins?" Right now, the answer is barely. That 55% satisfaction score is a warning sign, not a death sentence. Vercel has resources, talent, and momentum. But they need to address complexity before the satisfaction gap becomes an adoption gap.
Astro won the content site market. Zero JS by default is such a profound advantage for content delivery that nothing else comes close. The Cloudflare acquisition gives it infrastructure backing that validates the approach. Astro doesn't need to beat Next.js. It needs to keep being the obvious choice for content sites, and it's doing that.
Remix is in genuine limbo. The merge into React Router was technically smart and strategically confusing. The Shopify backing is valuable but narrow. The AI pivot is unproven. Remix has the best data-loading abstractions in React, and somehow that's not enough to secure a clear market position. I think React Router v7 will survive as excellent infrastructure — the way Express survived even when Next.js ate the full-stack Node market. But Remix as a "framework you choose" is fading.
The real winner? It's the developer who stops asking "which framework is best?" and starts asking "what am I building, and which tool fits that?"
I've seen teams spend weeks evaluating frameworks for a marketing site and then choose Next.js because it's "the safe choice." They ship 100KB of JavaScript to render text. They configure server components for a page that could be static HTML. They fight caching rules for content that changes once a week.
I've also seen teams try to build a complex SaaS dashboard in Astro because "it's faster." Then they end up with a Frankenstein of React islands that share state through custom events and URL parameters, slowly rebuilding the React app they should have just built in Next.js.
Pick the boring, correct tool. Not the popular one. Not the one with the best marketing. Not the one your favorite YouTuber just made a video about. The one that matches what you're actually building.
That's it. That's the whole framework war, resolved in one sentence: use the right tool for the job, and stop pretending there's a universal winner.