Free lesson · React Deep Dive

What React Is and Isn't

Easy11 min readreactjavascriptfrontend

What React Is and Isn't

The last lesson of the module. This one closes the conceptual frame by placing React next to its alternatives - Angular, Vue, Svelte, SolidJS, Qwik - and by addressing a question that's gotten increasingly fuzzy: is React a library or a framework?

The honest answer is "it depends on the year you're asking." React started as a library (and the team still describes it that way). It's now usually used inside a framework (Next.js, React Router 7) that gives it the surrounding scaffolding. The library-vs-framework distinction is real and worth understanding; it's also blurring in ways that affect how you should think about React's place in 2026.

I'll try to be opinionated here without being unfair. I work on React projects at Microsoft; I've also evaluated alternatives for specific use cases. I have informed opinions but I'm not on the React team. Where another framework is genuinely better for a specific problem, I'll say so.

The Framework Versus Library Question

The classical distinction: a library is a tool you call; a framework is a tool that calls you. With a library, your code is in charge of when and how to use the library's functions. With a framework, you fill in pieces inside a structure the framework provides.

By this definition, React was clearly a library at first. You'd write your app's code; somewhere in it, you'd render React into a DOM node. React did one thing - render UI from components. Everything else - routing, data fetching, build tools, deployment - was up to you.

This was deliberate. The React team has historically been allergic to opinions about the surrounding ecosystem. The reasoning: different applications have different needs; if React picked a router or a build tool, it'd be wrong for some fraction of users. Better to do one thing well and let users compose.

flowchart TB
    subgraph App["Your Application"]
        Router["Router (you choose)"]
        Data["Data fetching (you choose)"]
        Build["Build tool (you choose)"]
        Styling["Styling (you choose)"]
        State["State management (you choose)"]
        React["React<br/>(component model + rendering)"]
    end

    style React fill:#a78bfa,stroke:#8b5cf6,color:#000

A diagram of how React fits in an application  - classically. Your application is a box; inside it, you choose your own router, your own data fetching library, your own build tool, your own styling approach, your own state management. React sits inside that box, doing one thing  - providing the component model and the rendering primitive. The other boxes around it are decisions you make. This is what's meant by React being "a library, not a framework"  - it's the rendering core, not the whole assembly.

This had real strengths. The React ecosystem became enormous; for almost every concern, there are multiple high-quality solutions; you compose what works for your project.

It had real weaknesses too. A new React developer staring at a blank project had decisions to make before writing the first line of UI: which router? which build tool? which state library? which testing setup? The freedom to choose was overwhelming for beginners and exhausting for teams that just wanted to ship.

This tension is what produced the frameworks. Next.js emerged as the most prominent - a framework built on top of React that made the choices for you. Routing? File-system-based. Build tool? Configured for you. Data fetching? Server-side built in. Styling? Whatever you want, with sensible defaults. Authentication? Examples in the docs. Deployment? Vercel, or any Node host.

By 2024-2025, the most common way to start a React project wasn't create-react-app (which was deprecated) or even raw Vite; it was create-next-app. The "React is a library" framing is still technically true - but for most developers, React is the engine inside a framework. The library/framework distinction blurs.

We'll come back to this in Module 25 when we cover Next.js properly. For this lesson, you should understand: React itself is a library; modern React applications are usually built inside a framework. Both statements are true.

React vs Angular

Let me run through the major alternatives. I'll be brief on each because dedicated comparison articles cover the details better than I can in a lesson. The goal is to give you the shape.

Angular (Google, current major version 19 as of late 2024). Distinct from AngularJS 1 - different product, different team, different language even (Angular is TypeScript-first; AngularJS was JavaScript). Released 2016; has its own loyal community, especially in enterprise.

How it compares to React:

• Angular is a framework, not a library. It's the comprehensive option: routing, forms, HTTP, dependency injection, state management - all built in. You don't pick a router; you use Angular's router.
• Different mental model. Angular uses templates (HTML files with directives) rather than JSX. Components have separate template files, style files, and TypeScript files. The mental model is more "MVC" than React's "function from state to UI."
• Two-way binding by default. Angular has it; you can use one-way binding too, but the default is two-way for form inputs.
• More ceremony. Angular is more opinionated about file structure, naming, module organization. This is good or bad depending on your taste - good for large teams that want enforced consistency, more friction for solo developers.
• TypeScript-first. Strong typing through and through. React supports TypeScript well but doesn't require it.

When Angular is the right choice: large enterprise teams that benefit from convention enforcement, teams that explicitly value Angular's all-in-one nature, contexts where Google's institutional support matters.

When React is better: most other cases.

React vs Vue

Vue (Evan You, currently major version 3). Started in 2014 as a one-person project; has grown into a mature alternative. Especially strong in the Chinese-speaking developer community; mainstream worldwide.

Vue is structurally similar to React in many ways. Component model, virtual DOM (Vue 3 still has one), reactivity. But it makes different specific choices:

• Templates, not JSX. Vue's .vue files have a template section (HTML-like markup), a script section (JavaScript), and an optional style section. The template syntax has its own directives (v-if, v-for, v-bind) and feels more like HTML than React's JSX-is-JavaScript model.
• Reactivity via getters/setters (Vue 2) or Proxies (Vue 3). Vue's state automatically becomes reactive - you don't call setState or setCount. You mutate the state and Vue re-renders. Feels magical compared to React's explicit updates; can be confusing about what triggers what.
• Two-way binding via v-model. Vue makes two-way binding easy. React deliberately doesn't.
• Smaller, more curated ecosystem. Vue has fewer "valid options" for things like state management and routing - the official Vuex/Pinia for state, Vue Router for routing. The choices feel more obvious.

Vue's strengths: gentler learning curve, less boilerplate, more "batteries included" feel. Its weaknesses: smaller ecosystem, fewer jobs, less corporate backing than React.

When Vue is the right choice: smaller teams, projects where developer experience and quick onboarding matter most, contexts where the curated ecosystem is a feature.

When React is better: most other cases, especially anywhere ecosystem maturity matters.

React vs Svelte

Svelte (Rich Harris, currently version 5). Started 2016 from a different premise than React or Vue.

Svelte's bet: what if the framework was a compiler, not a runtime?

React (and Vue, and Angular) ship a runtime to the browser. Your app contains React's code that interprets your components and runs the rendering logic. Svelte compiles your components down to vanilla JavaScript that directly manipulates the DOM. There's no Svelte runtime in production - it's been compiled away.

Implications:

• Smaller bundles. A Svelte app with the same UI as a React app ships less JavaScript because there's no framework runtime.
• Different mental model. Svelte components use a syntax that's neither JSX nor templates exactly - it's its own thing. State is just variables; reactivity comes from a compile-time analysis of which variables affect which DOM nodes.
• No virtual DOM. Svelte updates the DOM directly. This is faster in some cases, slower in others; mostly it's just different.
• SvelteKit is the framework. Svelte's equivalent of Next.js. Solid, but newer and smaller than Next.js.

Svelte's strengths: smaller bundles, less framework overhead, often less code for the same UI. Its weaknesses: smaller ecosystem, less corporate backing, fewer jobs.

When Svelte is the right choice: projects where bundle size matters disproportionately (low-bandwidth contexts, performance-critical applications), or where the developer experience aesthetic matters and Svelte's matches yours.

When React is better: most enterprise and team contexts where ecosystem and hiring matter.

React vs SolidJS

SolidJS (Ryan Carniato, version 1.x stable). Newer; gaining traction especially among React engineers looking for "what's next after React."

Solid's mental model is closer to React than Vue or Svelte's is, but with one specific divergence: fine-grained reactivity instead of component-level re-rendering.

In React, when state changes, the whole component re-renders (and React figures out what to update in the DOM). In Solid, when state changes, only the specific DOM nodes that depend on that state are updated - no component-level re-execution.

Implications:

• Performance characteristics differ. Solid is often faster for highly interactive UIs; the per-update cost is lower.
• Different reactivity primitives. Solid has createSignal instead of useState. The API looks similar but the semantics are different - Solid signals are subscribed to where they're used, React state triggers component re-renders.
• Compatible-looking syntax. Solid uses JSX. Components look superficially like React. The mental model is genuinely different though.
• Smaller ecosystem. Newer; less corporate adoption.

Solid is interesting to watch. Some of its ideas (signals especially) have influenced React's evolution. The React Compiler does at compile time what Solid does at runtime - automatic fine-grained updates.

When Solid is the right choice: performance-critical UIs where Solid's reactivity model produces noticeable wins, projects willing to bet on a smaller ecosystem.

When React is better: when ecosystem and adoption matter, which is most contexts.

React vs Qwik

Qwik (Misko Hevery - also created Angular - current version 1.x). Most recent of the alternatives.

Qwik's bet: resumability instead of hydration.

When a React SSR app loads, the server sends HTML, the browser parses it, then the client loads the React runtime and "hydrates" the HTML - attaches event listeners, recreates component state. This hydration step is significant work, especially for large apps.

Qwik skips hydration. Instead, the framework serializes enough state into the HTML that the app can resume from any interaction point without needing to "wake up" the whole app first. Interactions trigger code loading on demand.

Implications:

• Very fast initial load. No hydration cost.
• Different mental model. Components have explicit serialization boundaries; code splitting is automatic and fine-grained.
• Smallest ecosystem of any of these alternatives. Newest.

Qwik is the most experimental of these. Its ideas might end up in React (or in React's future) the way Solid's have influenced the React Compiler. It's a project to watch, not (yet) a project to bet a production app on, unless you have specific reasons.

The Framework Era

Now back to the framework-vs-library question with this context.

A few years ago, comparing React to Vue to Svelte was comparing libraries (or library-cores) to each other. Today, the comparison is usually Next.js vs Nuxt (Vue's framework) vs SvelteKit vs SolidStart. Each major UI library has a canonical framework built on top.

This is the modern reality. When you start a React project at a company, you almost certainly start with Next.js, occasionally with React Router 7 in framework mode (which merged with Remix in 2024). You almost never start with raw React + raw Vite + roll-your-own-router for a serious project anymore.

The framework era changes what "React" means in practice. The React team's official position is still "we're a library." But the average React developer's experience is closer to "we're a framework," because Next.js or React Router 7 makes most of the surrounding decisions. The library/framework distinction matters less for the user and more for the ecosystem.

Module 25 covers this transition fully. For this lesson, the takeaway: modern React is usually used inside a framework. Pick the framework as deliberately as you pick the library underneath it.

Which One Should You Use?

You're learning React. So you've already implicitly answered. Let me give the honest version of the answer anyway, because at some point you'll be in a position to make this choice for a team or project.

Use React when:

• Ecosystem maturity matters (and it usually does).
• Hiring matters (React has the largest developer pool).
• You want corporate backing (Meta is committed; the React team is well-resourced).
• Your project's needs are common - typical web apps, dashboards, content sites, e-commerce.

Use Angular when:

• You're in an Angular shop (it's hard to mix in non-Angular contexts).
• Enterprise convention enforcement matters more than flexibility.
• You're building inside Google.

Use Vue when:

• You explicitly prefer Vue's syntax and conventions.
• You're working with a team that knows Vue.
• You're in a region where Vue has stronger adoption than React.

Use Svelte when:

• Bundle size matters disproportionately.
• You're building something that benefits from the smaller framework overhead.
• You're willing to trade ecosystem size for developer experience.

Use Solid, Qwik, or other newer frameworks when:

• You have a specific reason - performance characteristics, mental model preference, willingness to bet on early ecosystem.
• You're building something where the specific tradeoffs match your project.

For most engineers reading this, React is the right answer. That's why the course exists. But knowing what React isn't is part of knowing what React is. Engineers who can articulate the comparisons interview better and make better architectural decisions later.

Closing Thoughts on Module 1

You've done the history. The pre-React world; Facebook's specific problem; the three philosophical commitments; the evolution from classes through hooks to Server Components; React's place in the framework landscape. That's the conceptual frame.

Module 2 starts the work. You'll set up a development environment, write your first component, and start building the actual skills. Everything in Module 2 onward assumes you've read this module - when I say "declarative UI" or "unidirectional data flow" or "hooks era," I'll be assuming you know what I mean.

If anything in this module felt unclear, this is the time to re-read. Once Module 2 starts, the pace picks up and the assumed foundation is what's in this module.

And one piece of advice from somebody who switched careers into this: don't try to know everything before you start writing code. The history I gave you is useful framing; it's not a prerequisite to writing your first useState. Many of the things in this module will only click after you've used React a bit. Re-reading after Module 5 or Module 10 will surface things you missed on first pass. That's fine. Read once carefully now; come back when you have more context.

What I Want You to Take From This Lesson

Six things.

One: React started as a library; modern React is usually used inside a framework. Both statements are true.

Two: The major alternatives are Angular, Vue, Svelte, SolidJS, and Qwik. Each makes different specific choices.

Three: Angular is the all-in-one framework. Vue is React-shaped with different syntax. Svelte is a compiler. Solid is signals-based. Qwik bets on resumability.

Four: React's strengths are ecosystem maturity, hiring depth, and corporate backing. Its weaknesses are fragmentation of choices and learning-curve overhead.

Five: The framework era (Next.js, React Router 7) is the present. Module 25 covers this in depth.

Six: Use React when ecosystem and hiring matter, which is most contexts. Use alternatives when you have specific reasons.

Try It

Exercise: Warmup (15 minutes). For each of Angular, Vue, Svelte, and SolidJS, write one sentence explaining the core difference from React. Don't look at the lesson; force yourself to recall.

Exercise: Core (30 minutes). Read the Vue 3 docs introduction end to end. Compare the framing to React's "Thinking in React." Note what's similar; note what differs.

Exercise: Core (30 minutes). Read Rich Harris's "Frameworks without the framework" post - Svelte 3's manifesto. Notice how its critique of React frames the alternatives.

Exercise: Stretch (60 minutes). Read the Solid documentation's "Thinking Solid" guide. Note specifically how Solid's signals model differs from React's hooks model. This will be useful context later when we cover React's evolution and the influence of signals on the React Compiler.

Back to React Deep Dive