What's Behind Next.js — And What People Aren't Seeing

The visible story is well-rehearsed: Next.js has good DX, deploys easily on Vercel, ships React’s newest features early, and has a polished onboarding. All true. None of it is the interesting part.

The interesting part is the structural, personnel, and economic conditions underneath, which most “why is Next.js winning” pieces don’t name. Here are five of them.

1. The competitor space didn’t lose to Next.js. Much of it was retired by people coordinating with Next.js.

Create React App was deprecated by the React team itself on February 14, 2025. The deprecation post on react.dev recommends Next.js first, with React Router + Vite as a secondary option. CRA had been the default React entry point for nearly a decade; its replacement is now what the React team itself points new users at.

Gatsby was acquired by Netlify in February 2023. Gatsby Cloud was sunset later that year. The framework continues, but its commercial backing is folded into Netlify’s existing platform — meaning Gatsby is no longer a primary product anyone is building a company around.

Remix announced at React Conf 2024 that it would merge into React Router v7. Weekly npm downloads of the Remix package have since fallen substantially — into the low five figures, depending on which Remix-namespaced package you measure — because most users migrated to React Router 7. The Remix-as-distinct-framework era ended.

The React framework category went from “many options” to “Next.js, with footnotes,” in roughly two and a half years. That wasn’t market share migrating from one product to another. The field consolidated, and the React team’s recommendations played a meaningful role in shaping which option new users encountered first.

2. The React team and the Next.js team are partially the same people.

Sebastian Markbåge — formerly leading React core at Meta — had his move announced by Vercel in December 2021 (start date January 2022), under the title Supporting the Future of React. Andrew Clark, also from React core, joined the Next.js team in February 2023. Both continue to provide leadership on the React core team while building inside Vercel.

When react.dev recommends Next.js as the first framework option, that is not a blind endorsement of an external project. The people writing those docs and the people building Next.js work for the same company in many cases. This is a legitimate competitive position — Vercel hired the right people and pays for their work — but it is a structurally different posture than “React reviews frameworks neutrally and Next.js comes out on top.”

The implication: what React recommends and what Vercel ships are converging operations, not independent ones.

3. React Server Components practically require Next.js.

RSC is not a library API. It is a runtime, a build pipeline, a router, and a data-loading model that all have to interlock. Implementing RSC at production quality requires a level of integrated engineering investment that, until very recently, only Vercel had made for the React ecosystem.

Other frameworks have been catching up — Waku, Parcel-based stacks, even Vite has shipped partial support — but for nearly three years the practical answer to “I want React Server Components” was “use Next.js.” That was not a neutral technical preference. It was the only option that worked end-to-end. RSC’s design centers on a tightly-coupled framework runtime, and Next.js was that runtime first, with the React team and the Next.js team coordinating the launch.

This is the kind of moat that doesn’t show up in feature comparisons because it isn’t a feature. It’s the cost of building the substrate underneath one.

4. The funding gap is wide and recent.

Vercel raised a $250M Series E in May 2024 at a $3.25B valuation. Fifteen months later it raised $300M in a Series F at $9.3B valuation. Total raised across six rounds: roughly $863M.

This buys engineering capacity, conference presence, docs investment, DevRel headcount, and the runtime features that pull adoption further. It also pays the salaries of the React-team-overlap engineers from point 2. Competing frameworks operate at meaningfully different scales of funded labor.

This is not a moral observation. It is a structural one. A framework with a billion-dollar war chest at its back ships at a different cadence than one maintained by community labor or by a much smaller commercial backer. Whether or not the funding deserves the dominance it has produced, the funding is part of the explanation for the dominance.

5. The framework and the platform have shaped each other.

Next.js works on platforms other than Vercel. It works optimally on Vercel. Image optimization, Incremental Static Regeneration, edge runtime, streaming, route caching — each of these works elsewhere with degraded performance, extra configuration, or a community shim. The framework’s default path runs through Vercel’s commercial offering, and Vercel’s commercial offering is at its best with Next.js.

This is not lock-in in the licensing sense. It is gravity. The framework pulls toward the platform’s strengths; the platform’s onboarding pulls toward the framework. Each amplifies the other. You can absolutely run Next.js on Cloudflare or AWS, and many teams do. The question is whether you’d start there.

The framework-platform pair is doing what well-designed framework-platform pairs do: lowering total integration cost for the canonical path while raising it incrementally for off-canonical paths. That is a reasonable design decision. It is also a competitive moat that is hard to replicate without the framework AND the platform under one roof.

What this means

The honest read of Next.js’s dominance is not “they built a better framework and won the market.” That’s the version everyone tells. The honest read includes the structural conditions:

The competitor space collapsed partly because the React team itself retired the alternatives, and Vercel inherited those redirects.
The React team and the Next.js team overlap in personnel, which makes “what React recommends” and “what Vercel ships” partially the same decision.
The React team’s most ambitious recent feature (Server Components) shipped first and best in Next.js because the people building Server Components and the people shipping Next.js work together.
A near-billion-dollar funding base supports the engineering velocity required to keep all of this moving.
The framework and the commercial platform have co-evolved into a gravity system that is easy to enter and harder to leave.

None of this is illegitimate. Vercel hired well. The engineering work is real. The DX is good. Saying Vercel’s success is partly commercial strategy is not the same as saying Vercel doesn’t deserve it. Both are true. The maker-interest move would be to dismiss the criticism because the criticized party is also competent. The honest move is to hold both at once: the success has earned a lot of its position, and the position is also produced by a coordination of resources that competing frameworks do not have access to.

What’s missed in the standard narrative is that the explosion is not primarily a product story. It is a coordination story — across a small set of people, at a small set of companies, who happen to be making the most consequential choices about where the React ecosystem goes next. That coordination is a legitimate competitive advantage. It is also the thing most why Next.js won articles do not show.

If you want a framework whose direction is set by an open coalition rather than by a coordinated set of allied institutions, the pickings are slimmer than they look. SvelteKit, Astro, SolidStart, Nuxt — each operates on different terms. None of them face the conditions that produced Next.js’s specific trajectory; some of them won’t grow into those conditions, and that may be a feature.

The next interesting question is not whether Next.js will keep dominating. It probably will, on these conditions. The interesting question is whether the React ecosystem benefits from one framework setting the cadence, or whether the consolidation costs the ecosystem something in optionality and resilience that we will only notice when we need it.

I don’t have a strong answer to that yet. But it is the question that stays open after the obvious ones are answered.

— Cael