What React actually is (and isn't)
React is a JavaScript library for building user interfaces, originally released by Facebook in 2013 and maintained since by Meta and a large open-source community. That framing matters: it's a library, not a framework. It handles the view layer — rendering components, managing updates to the DOM — and leaves routing, data fetching, and state management to other tools. Everything ships under the MIT License.
The core idea is declarative UI: instead of issuing imperative commands ("find this node, change this attribute"), you describe what the interface should look like for a given state, and React works out the minimum set of DOM mutations needed to get there. That's what the virtual DOM does — it's a lightweight in-memory representation of the real DOM that React diffs against before committing updates to the browser. Less touching the DOM, fewer repaints, more predictable behaviour.
Components are the other load-bearing concept. A React component is a function that takes props (external data) and optionally holds internal state; it returns a description of UI. Because components are just functions, you compose them the same way you'd compose any functions — small ones into larger ones, all the way up. Logic lives in JavaScript, not in framework-specific templates, which means your existing JS skills transfer directly.
React Native extends the same model to iOS and Android, and server-side rendering — first via Node-based solutions, now formalised through frameworks like Next.js — means the library is genuinely runtime-agnostic. That flexibility is a real competitive advantage.
The honest picture in 2025
React is still, measurably, the most-used front-end library. It dominates job boards, it's the default choice at most product companies, and its ecosystem — Next.js, React Query, Zustand, Radix UI — is wider than any competitor's. If you're joining a team or hiring one, the odds that the codebase is React are high.
But the case for React as the obvious default has weakened. The reasons are concrete.
Bundle size and runtime cost. React ships a non-trivial runtime that must download, parse, and execute before your UI becomes interactive. Svelte compiles components to vanilla JS at build time — no runtime — which can deliver measurably smaller bundles and faster time-to-interactive on modest hardware. Solid takes a similar compile-first stance. For content-heavy or performance-sensitive sites, that gap is real.
Reactivity model. Vue 3's Composition API and Solid's fine-grained reactivity both track dependencies at a more granular level than React's component-level re-render model. React's solution — useMemo, useCallback, and now the React Compiler — works, but it means more cognitive overhead than "it just updates the thing that changed."
Complexity creep. Hooks were a genuine improvement over class components when they landed in React 16.8, but the mental model for useEffect trips up experienced developers regularly. The async-await mental model problem is well-documented elsewhere; useEffect's dependency array is its own version of that — a sharp edge that beginners hit early and seniors still debate.
None of this means React is wrong. Its stability is a feature, not a consolation prize. Meta's investment, the sheer volume of maintained packages built around it, and the React team's work on Server Components and concurrent rendering mean it keeps moving. Choosing React for a large team, a long-lived product, or a project that needs a big hiring pool is still a defensible decision.
What's changed is that the alternatives now make the decision worth having. Vue, Svelte, and Solid aren't compromises — they're genuine frameworks with coherent ideas and production pedigrees. If you're deciding which front-end framework fits what you're building, the answer might well still be React. But "everyone uses React" is no longer sufficient justification on its own.
Defaults deserve revisiting. React has earned its position; it just hasn't earned permanent immunity from the question.