Introduction
Job postings list React under frameworks. Developers argue about it in forums. Yet React's own documentation has always called it a library — and that distinction is not a minor technicality.
The library-vs-framework question directly shapes how teams architect applications, which tools they add to their stack, how they approach SEO, and what they expect new developers to know coming in. Misclassifying React leads to real gaps — missing routing, no server-side rendering, an under-built stack.
This article clarifies exactly what React is, how its architecture works, why it differs from true frameworks like Angular, and when you should reach for a React-based framework like Next.js versus using React on its own.
TLDR
- React is a JavaScript library, not a framework — officially confirmed by react.dev
- The core distinction: libraries let your code call them; frameworks call your code (inversion of control)
- React has no built-in routing, data-fetching, or enforced file structure — developers assemble those separately
- Next.js, Gatsby, and React Native are frameworks built on top of React, not replacements for it
- Choosing bare React vs. a React framework comes down to SEO needs, rendering strategy, and project scale
Library vs. Framework: Understanding the Core Difference
The terms get used interchangeably in casual conversation, but the distinction is precise.
What Is a Library?
A library is a collection of pre-written code — functions, components, utilities — that you call when you need it. Your application controls the flow; you decide when to invoke the library and when to move on. React is the clearest example of a UI-focused library: you call React's rendering functions, and React doesn't dictate when or how your application runs.
What Is a Framework?
A framework provides an opinionated structure for your entire application. It prescribes how you organise files, handle routing, manage data, and build features. It also controls execution — the framework calls your code at the right moments, not the other way around.
Martin Fowler describes this as "inversion of control" — the single clearest dividing line between a library and a framework. With a library, your code calls the library. With a framework, the framework calls your code.
Examples Side by Side
| Category | Examples |
|---|---|
| Libraries | React, jQuery, Lodash, Axios |
| Frameworks | Angular, Django, Ruby on Rails, Laravel, Spring Boot |
| Minimal frameworks | Express.js (lightweight, few conventions) |
| Full-featured frameworks | Django, Angular (batteries-included, highly opinionated) |
The practical difference shapes how teams work:
- Frameworks reduce decision-making — routing, file structure, and tooling come pre-decided
- Libraries maximise flexibility but require assembling your own stack
Neither is inherently better; the right choice depends on your project's scope and your team's preferences.
Is React a Framework? The Clear Answer
React is a JavaScript library — not a framework.
React's official homepage describes it as "The library for web and native user interfaces." The React npm package reinforces this: it contains only the functionality necessary to define React components — no routing, no HTTP handling, no global state management.
Why React Fails the Framework Test
React doesn't meet the framework criteria on multiple counts:
- No built-in routing — you install React Router separately
- No data-fetching layer — teams add Axios, TanStack Query, or similar tools independently
- No enforced file structure — you organize your project however you choose
- No prescribed architectural pattern — MVC, feature-based folders, atomic design — all valid, none required
- No inversion of control — React doesn't call your application; you decide when components render, when data fetches, and how navigation works
Where the Confusion Comes From
React is often called a framework colloquially because it sits at the center of large application stacks. Being the foundation of a stack, though, isn't the same as being a framework.
Angular makes for a clean contrast:
| Capability | React | Angular |
|---|---|---|
| Routing | External (React Router) | Built-in |
| HTTP client | External (Axios, TanStack) | Built-in HttpClient |
| CLI tooling | Optional | Core part of the package |
| Forms handling | External | Built-in |
| Enforced structure | None | Yes |
Angular tells you how to structure your application. React hands that decision back to you.
React Has Grown Beyond a Simple Library
React now provides more than just rendering. React 18 introduced concurrent rendering — an interruptible rendering model — and React Server Components define a new component type that renders ahead of time outside the browser. These are architectural decisions that frameworks like Next.js build on.
That positions React as something layered: a rendering library at its core, an architectural standard in practice, and an ecosystem that other frameworks build on top of. The label "library" undersells it — but "framework" is still the wrong word.
React's Core Architecture: What Makes It a Library
Understanding React's architecture explains why it functions as a library rather than a framework. Everything React does is scoped to the UI layer.
Components and the Rendering Model
React applications are built from components. Each component is a reusable, composable piece of UI that manages its own state and rendering logic — you nest them together to build pages, then applications. React only updates the parts of the UI that actually change, skipping a full re-render.
Data flows in one direction: from parent components down to children via props, with events travelling back up through callbacks. This is React's unidirectional data flow — a deliberate choice that keeps rendering predictable and state easy to trace.
Compare that to Angular's two-way data binding, where UI changes automatically update the model and vice versa. React keeps those concerns separate by design.
The Virtual DOM and Reconciliation
React maintains an in-memory copy of the real browser DOM, called the Virtual DOM. When state changes, React runs a diffing algorithm to compute what changed between the current and new Virtual DOM, then applies only the minimum necessary updates to the real DOM.
This process, called reconciliation, uses a heuristic O(n) algorithm built on two assumptions:
- Different element types produce different trees
- Stable keys indicate stable child components
The result is efficient, targeted DOM updates without re-rendering the entire page.
JSX
JSX is a syntax extension that lets developers write HTML-like markup inside JavaScript. React compiles it to standard JavaScript at build time. It's React's preferred authoring pattern, but not mandatory — React works without JSX, though very few teams skip it in practice.
React-Based Frameworks: Where React Becomes the Foundation
Because React deliberately omits routing, SSR, and other full-stack concerns, an ecosystem of frameworks has grown around it to fill those gaps. These are frameworks built on React — not React itself transforming into a framework.
The Major React-Based Frameworks
Next.js is the most widely adopted. Next.js describes itself as "The React Framework" and adds file-system routing, server-side rendering (SSR), static site generation (SSG), React Server Components, and API route handlers. It puts React's newer architectural features — concurrent rendering and Server Components — into a production-ready structure.
According to the 2024 Stack Overflow Developer Survey (over 65,000 respondents), Next.js reached 16.79% developer usage.
Gatsby is a React-based static site generator that pre-renders pages at build time. It's best suited for content-heavy sites where performance, SEO, and fast page loads are priorities.
React Native extends React's component model to native mobile development for iOS and Android. It's not a web framework, but it demonstrates how React's architectural model travels far beyond the browser. For teams building cross-platform mobile apps — like those Codiot delivers for startups and enterprises — React Native means a single component model can serve both iOS and Android without rewriting the core logic.
In each case, React provides the component model and rendering engine. The framework layered on top decides how those components are routed, served, and deployed.
React or React + Framework: Choosing the Right Approach
The decision usually comes down to three factors: SEO requirements, rendering strategy, and project complexity.
When Bare React Works Well
React alone is a reasonable choice when:
- The app sits behind a login (authenticated dashboards, internal tools, admin panels)
- SEO is not a concern — crawlers won't need pre-rendered HTML
- The team wants full control over every architectural decision
- The project is relatively contained and doesn't need complex routing
Client-side rendering (CSR) with React is appropriate here. The browser downloads the JavaScript bundle and renders the UI. Simpler setup, more flexibility.
When a React Framework Makes More Sense
Reach for Next.js or a similar framework when:
- The app is public-facing and needs to rank in search engines
- Fast initial load times matter (SSR delivers HTML on the first request)
- The project requires static site generation for content-heavy pages
- Complex routing, API routes, or server logic are part of the build
The performance difference can be significant. Vercel's 2025 case study migrating Grep from Create React App to Next.js reported First Contentful Paint improving from 3.0s to 0.9s, Largest Contentful Paint dropping from 3.7s to 3.2s, and the search index expanding from 500,000 to 1,000,000 indexed repositories. These are vendor-reported metrics from a specific migration, not universal benchmarks — but they illustrate the performance ceiling that CSR-only React can hit for public applications.
For startups, SMEs, and enterprises weighing their frontend architecture, the framework choice has long-term consequences. Getting it right at the start avoids the costly work of retrofitting SSR or routing into an existing codebase — a pattern Codiot's development teams encounter regularly when helping clients migrate from bare React setups.
Frequently Asked Questions
Why is ReactJS not a framework?
React doesn't meet the core criteria for a framework. It has no inversion of control, no built-in routing or data-fetching, and no enforced file structure. Its scope is intentionally limited to UI rendering — everything else is left to the developer.
Is React a frontend or backend framework?
Neither — React is a frontend JavaScript library for building user interfaces that runs in the browser. When used with Next.js, React components can also render on the server (SSR), but React itself is not a backend framework.
Is Next.js a library or framework?
Next.js is a framework. It's built on React and adds file-based routing, SSR, SSG, and API routes — all of which meet the definition of a framework by providing opinionated conventions and controlling application flow.
What is the difference between React and Angular?
React is a UI library requiring teams to assemble their own routing, HTTP, and state management stack. Angular is a full-featured framework that ships all of those as core modules, plus CLI tooling and enforced MVC-style architecture. In practice, Angular suits teams that want structure built in; React suits teams that prefer to choose their own tools.
Can React be used without any framework?
Yes. React can be added to any webpage or used standalone with separately selected libraries — React Router for navigation, Redux or Zustand for state, Axios or TanStack Query for data fetching. This gives full control but requires more upfront configuration decisions.
What is the Virtual DOM in React?
The Virtual DOM is an in-memory copy of the real browser DOM. When data changes, React computes the difference between the old and new Virtual DOM and updates only the changed elements in the actual DOM — making UI updates faster than re-rendering the entire page.
