Is React a Framework? 110 of 139 Editions Say Next.js
React ships no router, no data layer, no build step and no server. Settled with inventory: 139 framework editions across 111 products, and the 9 built twice.
React is not a framework. It is a UI library that renders components and manages state, and it deliberately ships no router, no data-fetching layer, no build pipeline and no server. A "React framework" is the thing that supplies those four — Next.js, React Router v7, TanStack Start. This catalog settles the question with inventory rather than opinion: 139 framework editions across 111 products, of which 110 are Next.js and 10 are plain React.
The distinction, stated once
| Concern | Plain React gives you | A React framework adds |
|---|---|---|
| Rendering components | Yes — this is the whole library | — |
| Component state | useState, useReducer, context | — |
| Routing | Nothing. react-router is a separate package | File- or config-based routes |
| Data fetching | Nothing. fetch in an effect is your problem | Loaders, server components, or route-level fetching |
| Server rendering | A low-level renderToString primitive | SSR/SSG wired end to end, with hydration handled |
| Build & bundling | Nothing | A configured bundler, code splitting, asset pipeline |
| Backend endpoints | Nothing | Route handlers / server actions |
React's own documentation is unusually direct about this. It calls itself "the library for web and native user interfaces" and recommends reaching for a full-stack framework to build an actual app. The confusion in the search results is real, not manufactured — but it is a vocabulary problem, and the vocabulary has a correct answer.
What 111 shipped products chose
Every product in this catalog declares its editions in src/data/catalog.ts. An edition is a framework plus a build status plus a live preview:
export interface Edition {
framework: Framework;
status: "ready" | "coming-soon";
/** Live demo URL (Vercel deployment). Embedded by PreviewModal. */
previewUrl: string;
}
Counting the framework field across all 111 entries gives the distribution:
| Framework | Editions | Share |
|---|---|---|
| Next.js | 110 | 79.1% |
| React (plain, Vite-built) | 10 | 7.2% |
| Vue | 9 | 6.5% |
| Angular | 9 | 6.5% |
| HTML (no framework at all) | 1 | 0.7% |
139 editions, 111 products. The interesting number is not 110 — it is the shape underneath it:
- 101 products ship Next.js only. Every landing page and shop template in the catalog.
- 9 products ship four or five editions each — React, Next.js, Vue and Angular, with one of them adding a plain-HTML build. All nine are admin dashboards.
- 1 product ships plain React only (
asoc-ecommerce).
That middle row is the useful one, because those nine products are the same admin dashboard implemented separately in each framework. They are a natural experiment in exactly the question this keyword asks.
The nine products that answer the question directly
asoc-lura-admin, asoc-pulse-admin, asoc-estate-admin, asoc-crest-admin, asoc-scholar-admin, asoc-vertex-admin, asoc-apex-admin, asoc-clover-admin and asoc-admin each ship both a react edition and a nextjs edition of the same product. Same screens, same design system, same feature list. What actually differs between the two builds is precisely the list of things React does not do:
- Routing. The React edition carries a router dependency and a route table written by hand. The Next.js edition has a
src/appdirectory where a folder nameddashboardcontainingpage.tsxis the/dashboardroute. No table exists to drift. - Where the code runs. In the React edition, everything is client code by definition — the bundle is the app. In the Next.js edition it is the opposite default: a component is server-rendered unless it opts out, which is why this storefront has 92 components and only 24 of them are marked
"use client". - The server. The React edition has none; anything needing a secret goes to a separate backend. The Next.js edition can put it in the same repo — this storefront's own four route handlers (
/api/download,/api/webhooks/lemonsqueezy,/auth/callback,/blog/feed.xml) live beside the pages they serve.
The HTML edition of asoc-admin is the control in that experiment: the same dashboard with no framework and no library, which is possible precisely because a dashboard's hard parts are layout and data, not reactivity.
What "framework" buys, measured on this site
This storefront is itself a Next.js app, so the cost of the framework is auditable. It runs on 13 runtime dependencies — next, react, react-dom, the Supabase client pair, the MDX toolchain, lucide-react, @vercel/analytics, server-only, remark-gfm and rehype-slug. There is no router package, no data-fetching library, no state manager, and no bundler in that list. All four are the framework's job.
The 27 page files in src/app expand to over 400 URLs at build time, because three of them are dynamic segments that enumerate themselves:
// src/app/templates/[slug]/page.tsx
export function generateStaticParams(): Params[] {
return catalog.map((p) => ({ slug: p.slug }));
}
Plain React has no equivalent of that line. There is no build step that knows what a route is, so there is nothing to enumerate — you would ship one HTML file and resolve /templates/asoc-keystone-landing in the browser after the bundle loads. That difference is the entire reason the catalog's marketing pages are Next.js and not React: a template that renders its content only after JavaScript executes is a template that ranks for nothing.
So which one should you pick?
The honest rule, and the one this catalog follows:
| If the product is… | Pick | Why |
|---|---|---|
| A marketing site, landing page, storefront, blog | A framework (Next.js) | Content has to exist in the HTML before JavaScript runs |
| An authenticated dashboard behind a login | Either — plain React is fine | Nothing behind a login gets crawled, so SSR buys you little |
| A widget embedded in someone else's page | Plain React | You want a bundle, not a server |
| A site with no interactivity at all | Neither | The HTML edition exists for a reason |
That table is why 101 of 111 products here are Next.js and why all nine multi-edition products are admin dashboards: the dashboards are the only category where "plain React" is a genuinely defensible answer, so those are the only ones where offering the choice is worth the maintenance.
Common mistakes
| Mistake | What happens | Fix |
|---|---|---|
| Calling React a framework in a technical decision doc | The doc silently assumes routing, SSR and a build pipeline are included; none are | Name the framework you actually mean — Next.js, React Router v7, TanStack Start |
| Choosing "React" for a marketing site | Content renders only after the bundle executes; crawlers and social scrapers see an empty shell | Use a framework that prerenders, or accept that the page ranks for nothing |
| Assuming a React app can be moved to Next.js by copying files | The router, the data-fetching pattern and the client/server boundary all change at once | Port route by route, and decide per component whether it needs "use client" |
| Adding a state manager on day one | Most component state is local; this codebase ships zero state libraries across 92 components | Add one when you have a real cross-tree state problem, not before |
| Treating "framework" as the performance decision | The framework decides where code runs; bundle size is decided by what you import | Measure the bundle, not the label |
Frequently asked questions
Is React a framework or a library? A library. React renders components and manages component state. It ships no router, no data layer, no build tooling and no server, and its own documentation recommends adopting a full-stack React framework to build a complete application. Everything commonly described as "the React framework" is one of those.
What is the most used React framework? Next.js, by a wide margin in this catalog's own inventory — 110 of 139 editions, and the only framework used by every landing page and shop template here. React Router v7 (formerly Remix) and TanStack Start are the other two credible full-stack options.
Can you build a whole website with just React? Yes, and the result is a single-page app: one HTML file, with routing resolved in the browser after the bundle loads. That is fine behind a login and bad for anything that needs to be indexed, which is why the plain-React editions in this catalog are all admin dashboards.
Does using a framework mean more dependencies? Usually fewer. This storefront's 13 runtime dependencies include no router, no bundler, no data-fetching library and no state manager, because the framework supplies all four. A plain-React build of the same app adds each of them back as separate packages you version yourself.
Templates in this post
ASoc Hearth, ASoc Ignite and ASoc Iris are three of the 101 products in this catalog that ship a Next.js edition only — marketing pages, where prerendered HTML is the whole point.
Browse the full sets: Next.js landing page templates, Tailwind landing page templates. For the same question asked against specific alternatives, see React vs. Remix, Next.js vs. Vue and React vs. Gatsby; for how the client/server boundary is actually drawn in code, see React Server Components vs. Client Components.