Next.js Adoption Benchmark 2026: The Data

Ask ten developers whether Next.js is still "the safe choice" for a new project in 2026 and you'll get ten different, confidently-stated opinions. Half will point to X threads calling it bloated. The other half will point to the fact that it's still the framework every hiring manager's job post asks for. Neither side is usually backing it up with numbers.

So here's an attempt to actually back it up with numbers. This post pulls together public, verifiable data — npm download counts, GitHub star trends, and two of the most widely referenced annual developer surveys in the JavaScript/web ecosystem — into one place, so you can see what "adoption" for Next.js actually looks like right now, and how it's moved over the last two years, instead of guessing from vibes and Twitter screenshots.

This isn't a marketing deck and it isn't a hit piece. Every number below is cited, every source is linked, and where the data has real limitations (and it does), we say so instead of hiding it. By the end, you'll know exactly how Next.js's usage compares to Nuxt, Astro, and Remix/React Router, how developer sentiment toward it has actually shifted, and whether that shift should change what you reach for on your next project.

Why an Adoption Benchmark, Not Just Another "vs" Post

Most framework comparison posts are opinion pieces wearing a data costume — a table of checkmarks, a "winner" declared in the last paragraph, and zero sources you could go verify yourself. That's fine for a gut-check, but it's useless if you're trying to answer a real question like "is it still safe to bet a two-year SaaS roadmap on this framework."

An adoption benchmark is different. It doesn't ask "which framework is better" — that's subjective and depends entirely on your project. It asks a narrower, answerable question: how many developers are actually shipping with this framework right now, is that number growing or shrinking, and how do we know? Usage at scale is itself a signal — more usage generally means a bigger hiring pool, more Stack Overflow answers when something breaks, and a lower chance the framework gets abandoned mid-project. But a snapshot alone can't answer the "growing or shrinking" half of that — that needs a trend, which is exactly what most "adoption" posts skip.

Methodology: Where This Data Actually Comes From

Transparency matters more here than in a typical tutorial, so here's exactly what went into this benchmark:

npm download counts — pulled from npmtrends.com, which aggregates public npm registry download data, and cross-checked against independently published download figures from other analyses (cited inline below). This measures how many times npm recorded downloads of the package during the period, which is a proxy for active usage — an imperfect one, for reasons explained in the trend section below.
GitHub star counts — a slower-moving, harder-to-inflate signal of long-term community interest and visibility, pulled from the same npmtrends comparison pages, which surface live GitHub star counts alongside download data.
State of JS 2025 — the Devographics-run annual survey (closed November 2025, results published shortly after) that asks working developers what they actually use and how they feel about it.
Stack Overflow 2025 Developer Survey — the largest annual developer survey by respondent count, which tracks usage of web frameworks and technologies across the whole industry, not just the JavaScript ecosystem.

Every figure below is attributed to one of these four sources. Where a number comes from a third party's analysis of that data rather than the primary source itself, that's called out explicitly.

⚠️ Common Mistake (reading data like this): Treating npm download counts as a literal headcount of developers. A single CI pipeline that reinstalls dependencies on every commit can generate thousands of downloads a week on its own. Download counts are best read as a relative, noisy signal — how a framework compares to its direct competitors — not an absolute number of people using it. The section below goes into exactly how noisy.

Key Finding 1: Downloads and Stars — Next.js's Lead Is Still Large

Starting with a current snapshot before getting into the trend: weekly npm downloads and GitHub stars, compared across the major React and Vue meta-frameworks.

Framework	Weekly npm downloads (snapshot range)	GitHub stars
Next.js	~33–55 million, depending on the exact crawl (see note below)	~142,000
Astro	~4.5 million	~62,000
Nuxt	~1.8 million	~60,000

Source: npm package download statistics and GitHub repository data via npmtrends.com, snapshots taken across August 2026. Next.js's download figure is deliberately given as a range rather than one number — different snapshots of the same comparison page disagreed by tens of millions, which is exactly what "Key Finding 2" below digs into.

What this actually tells you: even at the low end of its range, Next.js is still roughly 7x Astro's weekly downloads and roughly 18x Nuxt's — an order-of-magnitude lead over its closest meta-framework competitors. That gap alone doesn't tell you Next.js is the better framework for your project (Astro is architecturally a better fit for a lot of content sites), but it does tell you the ecosystem, tooling, and hiring pool around Next.js are meaningfully larger right now.

Key Finding 2: Why This Post Doesn't Include a Multi-Year Download Chart

The rest of this post makes trend claims — Next.js "still" leading, its lead "isn't shrinking," Astro "gaining ground." Those are claims about direction over time, not a single point in time, so the obvious next step was to build a real Aug 2024 → Aug 2026 weekly-downloads chart to back them up properly. That turned into the most useful negative result in this whole benchmark: it isn't currently possible to build one from public data without presenting false precision, and it's worth explaining exactly why rather than shipping a chart that looks authoritative but isn't.

Two separate problems, found independently:

Problem 1 — no aggregator offers dated, independently-checkable historical data. npmtrends.com's comparison pages are live-only; there's no dated permalink that will still show August 2024's numbers when someone clicks it later. Any "historical" table built from what a search engine happened to have cached at some point isn't something a reader — or an editor fact-checking this post six months from now — can actually go verify. A citation that only worked at the moment the writer looked at it isn't a real citation.

Problem 2 — the underlying download numbers are themselves inconsistent, even within a single source. To find a workaround for Problem 1, we checked PkgPulse, a separate npm analytics site that explicitly claims to filter out CI/bot traffic. It didn't help — it made the case for caution stronger. Across three different PkgPulse pages, all published within about a month of each other in early 2026, Next.js's stated weekly downloads were reported as ~4.5 million, ~6.5 million, and ~39.6 million — an almost 9x spread from the same analytics provider, on pages published close together in time. That's on top of npmtrends' own comparison pages showing a roughly 33–55 million range for the same package across different crawls (see Key Finding 1's table above).

This lines up with what's independently documented about npm download data generally, not something specific to Next.js:

npm's own registry has recorded verified anomalies on its GitHub feedback tracker, including multi-day periods of zero recorded downloads for widely-used packages and sudden multi-week spikes with no corresponding release to explain them.
npmtrends.com's own client-side code contains a hard-coded outlier cap (publicly discovered by developers inspecting its bundle) that clamps any single day's download count above roughly 156,000 down to 70,000 before charting it — a tacit admission that raw registry numbers occasionally spike far beyond plausible organic usage.

What this means for the "trend" claims elsewhere in this post: they're supported by GitHub star growth and by two years of consistent survey results (State of JS has tracked Next.js as the dominant meta-framework in every recent edition, not just this one), not by a download-count time series — because no currently-available public source can responsibly produce one. Where this post says Next.js usage "isn't shrinking," that's a conclusion drawn from stars and surveys, and it's worth reading it that way rather than assuming a download chart backs it that we simply didn't show you.

⚠️ Why we didn't just publish one anyway: it would have been easy to pick one aggregator's numbers, round them into a clean-looking line chart, and move on — plenty of "original data" posts do exactly that. We're choosing not to, because a chart built on numbers this volatile would be worse than no chart: it would look more certain than the underlying data actually is, and a reader has no way to tell the difference between a rigorously-sourced chart and a plausible-looking one just by looking at it.

💡 Tip: If you need to make a real decision based on npm download trends — evaluating a dependency for your own team, for example — don't trust a single aggregator's absolute number, and be skeptical of a single aggregator's trend too. Cross-check at least two independent sources, and if they disagree by more than ~20–30%, treat the precise figures as unreliable and fall back on a more stable signal like GitHub stars or survey data.

Key Finding 3: Survey Usage Confirms the Same Pattern, From a Different Angle

Downloads and stars measure what gets installed. Surveys measure what developers say they actually reach for. It's worth checking both, because they can diverge — a framework can be widely installed as a transitive dependency without being anyone's first choice.

They don't diverge much here.

The Stack Overflow 2025 Developer Survey lists Next.js at roughly 20.8% usage among all respondents — developers across every stack, not just JavaScript. That places it as the fourth most-used technology in Stack Overflow's web frameworks and technologies question, behind only Node.js, React, and jQuery.
The State of JS 2025 survey — which only surveys people already working in the JavaScript ecosystem, so the base is narrower and the percentage naturally runs higher — puts Next.js usage at roughly 59% among respondents who answered the meta-framework question.

Two structurally different surveys, with different respondent pools and different questions, land on the same conclusion: Next.js remains the dominant choice among developers using JavaScript meta-frameworks.

💡 Tip: Notice these two numbers (20.8% and 59%) aren't contradictory even though they look wildly different — they're answering different questions. Stack Overflow asked a broad developer population which web frameworks and technologies they had worked with. State of JS asked "what do you use" only to people already building with JavaScript meta-frameworks. Always check what population a stat is drawn from before comparing two surveys directly.

Key Finding 4: Usage Is High, Satisfaction Is a Genuinely Mixed Story

This is the part that gets glossed over in most "Next.js is winning" posts, and it's the most interesting finding in this whole benchmark: usage and sentiment have clearly decoupled.

State of JS 2025 paints a much more mixed picture of Next.js sentiment. Next.js remains the dominant meta-framework at 58.6% usage, but its satisfaction score fell sharply—from 68% to 55%—the largest satisfaction decline highlighted in the survey. The project also generated the most comments overall, suggesting unusually strong polarization around the framework.

Recurring themes in the negative comments, based on the survey writeups referenced above, cluster around a few consistent complaints:

Perceived complexity growth — the jump from Pages Router to App Router, Server Components, and the caching model introduced genuinely more concepts to learn than the old getServerSideProps-era API surface.
Vercel-specific concerns — some respondents cited concerns around Vercel, deployment, and perceived platform lock-in, even though the framework itself remains open source and deployable elsewhere. See our breakdown of ISR/PPR support across hosting platforms if that's a concern for your own deployment target.
Migration fatigue — teams with large Pages Router codebases, moving to the App Router can represent a substantial architectural change rather than a simple version upgrade.

None of this means Next.js is declining in usage — the download and survey numbers above say the opposite. It means the "is Next.js good" conversation and the "is Next.js widely used" conversation are two separate questions with two separate answers, and it's worth keeping them separate in your own head when you're deciding what to build with.

Key Finding 5: Server Components Adoption Still Has Real Room to Grow

One more data point worth isolating on its own, since it's specific to the App Router rather than Next.js as a whole: independent industry analysis (cited via Netguru's 2025 React trends report) estimates that only around 29% of developers have actually used React Server Components in production, despite more than half expressing positive sentiment toward the underlying idea.

That's a meaningful gap between interest and adoption — and it lines up with what the App Router complexity criticism above would predict. A lot of developers are curious about Server Components conceptually, fewer have shipped something real with them yet. If you've been putting off learning the Server vs. Client Component split, you're statistically in the majority, not behind some curve everyone else has already cleared.

An Original Composite View: The DevStacked Adoption Index

Raw numbers from four different sources are hard to compare side by side, since they're measured on completely different scales (millions of downloads vs. a percentage vs. a star count). To make the picture easier to read at a glance, here's an original synthesis — not a new dataset, just a transparent way of putting the existing public numbers on the same footing. Because of the download volatility documented above, this index leans on the low end of each framework's observed download range rather than a single headline number.

Each framework is scored 0–100 on two axes, normalized against the highest value in this comparison set:

Install Share — weekly npm downloads (low end of the observed range), normalized against Next.js as the ceiling (Next.js = 100)
Star Share — GitHub stars, normalized against Next.js as the ceiling (Next.js = 100)

Framework	Install Share	Star Share
Next.js	100	100
Astro	~14	~44
Nuxt	~5	~43

How to read this table: Astro's Star Share is proportionally much closer to Next.js than its Install Share, indicating that its GitHub visibility and download footprint are less disproportionate than Next.js's. This is consistent with Astro's growing visibility, but the ratio itself should not be interpreted as a measure of production adoption.

⚠️ This index is illustrative, not scientific. It's a normalized view of two public metrics, built to make comparison easier — it isn't a peer-reviewed methodology, and it deliberately leaves out factors like job postings, Discord activity, or bundle size that a more rigorous study would weigh in. Treat it as a visualization aid on top of the cited numbers above, not a standalone data source of its own.

What This Actually Means If You're Choosing a Framework Right Now

Numbers are only useful if they change a decision. Here's the practical read:

If you're optimizing for hiring, ecosystem depth, and "will this still be maintained in three years" — Next.js's install base, download volume, and star trend are all large and stable-to-growing enough that this risk is close to zero right now, sentiment complaints notwithstanding.
If your project is content-heavy (marketing site, docs, blog) and doesn't need much client-side interactivity — Astro's content-focused architecture and growing adoption make it worth evaluating instead of defaulting to Next.js out of habit. See our full framework rendering strategies breakdown to understand where Next.js's SSR/SSG/ISR model genuinely earns its complexity versus where it's overkill.
If your team is Vue-first — Nuxt's numbers are smaller in absolute terms, but that's expected given Vue's smaller overall footprint versus React; within the Vue ecosystem specifically, Nuxt is the dominant meta-framework choice.
If the App Router's complexity is your specific hesitation — that concern shows up clearly in the sentiment data, and it's legitimate. The fix isn't necessarily switching frameworks; it's learning the caching model deliberately instead of picking it up by trial and error. Our Cache Components migration guide exists specifically because the App Router's caching model is one of the areas that often requires deliberate learning.

Limitations of This Benchmark

Being upfront about what this data can't tell you:

npm downloads don't equal production traffic, and — as shown above — different aggregators can disagree by several times over for the same package. Treat any single download figure, including the ones in this post, as directional rather than precise.
Survey respondents self-select. People who fill out the State of JS survey are, by definition, developers engaged enough with the JS community to know the survey exists — that skews toward more opinionated, more online developers than the average working programmer.
This post deliberately does not include a multi-year download chart, for the reasons explained in Key Finding 2. Every public npm download aggregator checked for this benchmark — including two independent ones cross-checked against each other — disagreed with itself or with the other source by several times over. Trend claims in this post lean on GitHub stars and multi-year survey results instead, which are more stable but say less about raw download volume.
"Usage" and "primary framework" aren't the same thing. Some respondents counted in these numbers might use Next.js at work but prefer something else for side projects, or vice versa. Surveys capture usage, not necessarily preference.

Frequently Asked Questions

Is Next.js actually declining in popularity in 2026?

No — the download, GitHub star, and survey data above all show Next.js with a commanding lead over its direct competitors, and none of the trend indicators checked here show that lead shrinking. What's changed is that criticism of its complexity has become more visible and vocal, which can feel like decline on social media even when the underlying usage numbers don't show one.

Why do npm download numbers for Next.js vary so much between sources?

npm download counts are known to include a large, variable share of automated traffic — CI pipelines, monorepo tooling, and infrastructure that reinstalls dependencies on every run — and different aggregators crawl and process the registry at different times and with different outlier handling. This is a documented issue across the npm ecosystem, not something specific to Next.js. GitHub stars and survey data are more stable signals for tracking direction over time.

Why do Stack Overflow and State of JS report such different usage percentages for Next.js?

They're surveying different populations. Stack Overflow surveys developers across every language and stack, so Next.js's 20.8% is a share of a much larger, more general pool. State of JS only surveys people already working in the JavaScript ecosystem, so its 59% figure is a share of a smaller, more specialized pool. Both can be accurate at the same time.

Should low satisfaction scores stop me from choosing Next.js for a new project?

Not on their own. Sentiment data reflects real, legitimate complaints — mostly around App Router complexity — but usage and satisfaction are separate metrics here, and Next.js's usage hasn't followed its satisfaction score downward. Weigh the specific complaints (are you worried about caching complexity? Vercel lock-in? migration cost?) against whether they actually apply to your project, rather than treating the satisfaction number alone as a verdict.

Is Astro a real threat to Next.js's dominance?

For a specific category of projects — content-heavy sites with light interactivity — yes, and the combination of faster relative download growth, a star-to-download ratio ahead of Next.js's, and strong State of JS satisfaction scores suggests Astro deserves serious attention for that use case. For interactive, data-heavy applications (dashboards, SaaS products, anything with complex client state), Astro isn't really competing in the same category as Next.js in the first place.

How often should a benchmark like this be updated?

Every 6–12 months is reasonable for framework adoption data — meaningful shifts in download trends or survey sentiment take real time to show up, and updating more frequently mostly just captures noise (see the download-volatility discussion above). Major version releases (like a future Next.js 17) or a new annual State of JS/Stack Overflow survey are natural triggers to refresh a benchmark like this one.

Wrapping Up

The honest takeaway from all of this: Next.js's adoption lead in 2026 is not in question, and it hasn't shrunk over the last two years by any indicator checked here — it's still the default choice for the majority of developers picking a React meta-framework, by a wide margin over Astro, Nuxt, and Remix/React Router combined. What is legitimately in question is whether that adoption reflects enthusiasm or inertia, and the sentiment data — a real, measured satisfaction drop alongside unchanged usage dominance — suggests it's genuinely a mix of both. That's a more useful, more honest answer than either the "Next.js is dying" hot takes or the "just use Next.js, no debate" defaults you'll see argued with equal confidence and zero sources.

If the App Router's caching model is the specific thing holding you back from feeling confident in this stack, that's a solvable, learnable problem rather than a reason to abandon ship — start with this Next.js 16 Cache Components guide.