Reading Grounds

React History Recap 2026

Take away points:

Influenced by functional programming, Facebook’s BoltJS experience and XHP’s component-like markup, React proposed that developers should describe the desired interface and allow the library to reconcile changes.

That model reshaped frontend development.

By 2026, React is no longer simply a browser-rendering library owned by Facebook. It supports web and native interfaces, anchors an enormous ecosystem, powers millions of public and private applications and now resides within an independent Linux Foundation-hosted organization.

Next.js has become React’s dominant full-stack framework, but it does not represent all React development. A vast production population still uses React with Vite, custom toolchains, separate backends and enterprise platforms that may never require Next.js.

React’s next era is centered on compilation, server coordination, streaming, intelligent scheduling and multi-company governance.

The question is no longer whether React changed user-interface development. It is whether React can continue changing it without losing the comparative simplicity that made developers adopt it in the first place.

React.js has become one of the most influential technologies in modern software development.

React.js has become one of the most influential technologies in modern software development. It changed how developers construct interactive websites, helped establish component-based user interfaces as the industry norm and expanded beyond browsers into native mobile and desktop applications.

React is frequently called a JavaScript framework, but its maintainers define it more narrowly: React is a JavaScript library for building web and native user interfaces [1]. It concentrates primarily on components, rendering and interaction. Features such as routing, application-wide data management, server integration and deployment are supplied by additional tools or full React frameworks such as Next.js.

Who Created React?

React was initially created by Jordan Walke, a software engineer working at Facebook—now Meta. However, the React that reached production and became an open-source project was the product of a growing Facebook engineering team rather than one person working alone.

Walke developed the central ideas and early prototype. Engineers including Pete Hunt, Tom Occhino, Christopher Chedeau, Sebastian Markbåge, Sophie Alpert, Dan Abramov, Andrew Clark and many others subsequently helped develop, explain and extend React.

Walke has generally remained a private figure. Former colleagues have described him as someone who preferred developing ideas and persuading engineers in individual conversations rather than becoming the public face of the project.

His work extended beyond React. He later created Reason, a programming language and toolchain connected to OCaml, reflecting his continuing interest in functional programming and better ways to construct user interfaces.

React’s origin is therefore best described as:

A foundational prototype created by Jordan Walke, developed into a production technology by a team inside Facebook and subsequently shaped by thousands of open-source contributors.

Today, React development is organized into working groups covering areas such as the server, DOM, Fiber renderer, documentation, developer experience, compiler and React Native [3].

Why Was React Created?

Around 2010 and 2011, Facebook’s interfaces were becoming increasingly interactive and difficult to manage. The company’s advertising interface and News Feed had to coordinate large quantities of constantly changing information.

The prevailing frontend architectures frequently separated applications into models, views and controllers. Developers then wrote code that manually synchronized application state with corresponding parts of the browser’s Document Object Model, or DOM.

As interfaces grew, it became difficult to answer a seemingly simple question:

When application data changes, exactly which pieces of the screen must also change?

A missed update could leave the interface inconsistent with its underlying data. Adding more two-way data binding and mutation could make the relationships even harder to follow.

Walke was interested in a more functional and declarative model. Instead of manually describing how to transform the existing screen, a developer would describe what the interface should look like for the application’s current state. React would determine the necessary DOM changes.

Conceptually:

UI = function(state)

That idea remains at the center of React. Developers create a component tree representing the desired interface, and React reconciles that description with what it previously rendered.

What Came Before React?

Two precursors are especially important to React’s history.

BoltJS: The Immediate Internal Context

Facebook had an internal JavaScript framework known as BoltJS. It supported much of the company’s interface development, but some difficult sections required engineers to leave its normal declarative model and write more complicated imperative code.

Walke experimented with a more functional alternative. Early versions reportedly passed through names including FBolt, for Functional Bolt, and FaxJS before becoming React [2].

XHP: An Important Conceptual Influence

React was also influenced by XHP, a Facebook extension to PHP that allowed developers to write XML-like user-interface elements inside PHP code [2].

XHP demonstrated that markup and application logic did not necessarily have to live in completely separate technologies. That idea reappeared in React’s JSX syntax:

function Welcome({ name }) { return <h1>Welcome, {name}</h1>; }

JSX initially looked wrong to many web developers because it placed HTML-like markup inside JavaScript. React’s argument was that separation should follow component responsibilities, not an artificial division between a template file and its related behavior.

React did not invent reusable UI components. Server-side template systems, desktop GUI toolkits and frameworks such as XHP all supplied precedents.

React’s breakthrough was combining components with:

• Declarative rendering
• One-way data flow
• State-driven updates
• Composable component trees
• An efficient reconciliation system
• Gradual adoption inside existing applications

How Long Did React Take to Create?

There is no authoritative public record saying that React took an exact number of weeks or months to create.

The available history shows an extended evolution:

• Early experimentation occurred around 2010 and 2011.
• React was deployed in Facebook’s News Feed in 2011.
• Instagram adopted it for its web application in 2012.
• Facebook publicly released React at JSConf US in May 2013 [2].

The first production-capable version therefore appears to have emerged within approximately a year of the formative experiments. React then spent roughly another two years being tested, expanded and defended internally before its open-source release.

It would be misleading to say React was simply “finished” in 2011 or that one person built the current library in a few months. The original idea reached production relatively quickly, but the technology developers now recognize as React resulted from more than a decade of continuing development and reconstruction.

React’s Difficult Open-Source Introduction

React was not universally welcomed when Facebook introduced it publicly in 2013.

Several ideas challenged accepted frontend practices:

• JSX mixed markup with JavaScript.
• React recreated descriptions of the UI during rendering.
• Its one-way data flow opposed popular two-way-binding systems.
• Its virtual-DOM approach was unfamiliar.
• Facebook released a library without providing every part of a complete application framework.

Some developers thought JSX violated separation of concerns. Others questioned whether repeatedly describing the UI could possibly perform well.

Facebook’s team had to demonstrate that React was not rebuilding the entire browser DOM after every state change. React constructed an in-memory representation, compared the new component output with the previous one and committed only the necessary changes.

The team’s greatest challenge was consequently not just implementing React—it was persuading developers to reconsider how UI code should be organized.

What Makes React Different?

React’s most distinctive characteristics are its declarative model, component system and renderer architecture.

Declarative Rendering

Imperative browser code describes a sequence of operations:

const heading = document.createElement("h1"); heading.textContent = "Welcome"; document.body.appendChild(heading);

React describes the desired result:

function Page() { return <h1>Welcome</h1>; }

When data changes, the component renders a new description. React determines what must change in the target environment.

This declarative model can make an application easier to reason about because developers describe the intended interface instead of manually coordinating every DOM operation.

Components Combine Related Responsibilities

A React component can contain:

• Rendering logic
• Event handling
• Local state
• Data transformations
• Lifecycle behavior
• Accessibility attributes
• Related styling decisions

This differs from architectures that require every concern to be divided into separate file types regardless of how closely the pieces work together.

React components can be as small as a button or as large as an entire page. Developers build complex interfaces by composing smaller components into larger component trees [1].

One-Way Data Flow

Data normally travels from parent components to children through properties, or props. Children communicate changes through callbacks, shared state or external stores.

This makes updates more explicit than systems in which changes automatically propagate in multiple directions.

React Is Renderer-Independent

React’s programming model is not limited to browser DOM elements. React DOM renders for the web, while React Native maps React components to native platform controls.

This division helped React become a model for building interfaces across multiple environments rather than merely an HTML templating system.

React Does Not Provide Everything

Unlike more comprehensive frameworks, React historically did not prescribe one router, networking layer, form system, state-management library or project structure.

That flexibility helped React enter existing applications gradually, but it also produced what developers sometimes call “React ecosystem fatigue.” Teams could face several competing solutions for every architectural decision.

React was designed for gradual adoption, allowing a development team to introduce individual React components without rewriting an entire existing application [1].

Major Milestones in React’s History

2011: Facebook News Feed

React’s early form entered production in Facebook’s News Feed. This established that its model could handle a complex interface with frequent state changes [2].

2012: Instagram

After Facebook acquired Instagram, React was used to develop Instagram’s web experience. This provided an important second production environment and helped demonstrate that the technology could extend beyond the codebase that created it [2].

2013: Open-Source Release

Facebook released React at JSConf US in May 2013. Initial skepticism gradually turned into rapid adoption as developers experienced the component model in real applications [2].

2015: React Native

React Native brought React’s component and state model to iOS and later Android. Instead of rendering HTML elements, React Native renders native interface components.

The project demonstrated that React was an architectural model rather than merely a browser library.

2016: Next.js

Vercel—then known as ZEIT—released Next.js to supply routing, server rendering and production conventions around React. Next.js would eventually become the dominant full-stack React framework.

2017: React Fiber

React 16 introduced the Fiber architecture, a reconstruction of React’s internal renderer. Fiber made it possible for React to divide rendering work, prioritize updates and eventually support concurrent rendering [2].

2019: Hooks

React 16.8 introduced Hooks such as useState and useEffect. Hooks allowed function components to use state and other React capabilities that had previously required class components.

Hooks simplified the reuse of stateful component logic, but they also created new debates involving dependency arrays, effects, closures and whether React’s programming model had become easier or merely different.

2022: React 18

React 18 introduced the new concurrent renderer, automatic batching, transitions and deeper Suspense integration.

These capabilities allowed React to prepare work, interrupt lower-priority rendering and coordinate server streaming with selective hydration.

2024: React 19

React 19 added Actions, useActionState, optimistic updates, the use API, improved metadata and resource handling, and stronger support for Server Components and Server Functions [4].

Actions reduced some of the manual work involved in handling pending states, errors, forms and optimistic updates. Server Components also pushed React further toward an architecture spanning both the client and server.

2025: React Compiler and React 19.2

React Compiler 1.0 became stable in October 2025. It can automatically optimize components and reduce the need for developers to manually apply useMemo, useCallback and React.memo [4].

React 19.2 added capabilities including:

• Activity
• useEffectEvent
• React Performance Tracks
• cacheSignal
• Server-rendering improvements
• Partial prerendering support
• Improved handling of Suspense boundaries [4]

2026: The React Foundation

In February 2026, React, React Native, JSX and related projects moved from Meta ownership into the independent React Foundation, hosted by the Linux Foundation [3].

The Foundation’s founding Platinum members are:

• Amazon
• Callstack
• Expo
• Huawei
• Meta
• Microsoft
• Software Mansion
• Vercel

React’s technical direction is intended to remain separate from the Foundation’s corporate board and continue being led by React’s contributors and maintainers [3].

This represents one of the most important organizational changes in React’s history. React began as a Facebook solution, became a Meta-led open-source project and is now moving toward independent, multi-company governance.

What Is React Used For?

React’s largest application remains web user-interface development, including:

• Single-page applications
• SaaS products
• Administrative dashboards
• E-commerce interfaces
• Social networks
• Streaming-media interfaces
• Educational applications
• Data-visualization systems
• Collaborative tools
• Content and publishing platforms
• Components embedded in existing server-rendered sites

React also reaches beyond conventional websites:

• React Native builds native mobile applications.
• Expo supplies a framework and tooling around React Native.
• Electron with React is commonly used for desktop interfaces.
• Custom React renderers can target televisions and other specialized environments.

React does not dictate what backend must be used. A React frontend can communicate with Node.js, Python, Ruby, PHP, Java, Go, .NET or almost any system that exposes an appropriate API.

The React Ecosystem

React’s comparatively focused core produced one of software development’s largest surrounding ecosystems.

Frameworks and Build Tools

• Next.js provides full-stack rendering, routing, Server Components, caching and deployment conventions.
• React Router supplies client routing and framework-oriented data APIs.
• Vite is a common development server and build tool for client-rendered React applications.
• TanStack Start offers a type-safe full-stack React approach.
• Astro can use React components selectively within content-focused sites.
• Expo is the leading framework around React Native.

State and Server-Data Tools

• Redux Toolkit
• Zustand
• Jotai
• MobX
• TanStack Query
• Apollo Client
• SWR

React’s own Context and Hooks can manage many local requirements, while these libraries address more specialized global or server-synchronized state.

Styling and Component Systems

• Tailwind CSS
• CSS Modules
• styled-components
• Emotion
• Material UI
• Chakra UI
• Radix UI
• shadcn/ui

Forms and Validation

• React Hook Form
• Formik
• Zod
• Yup

Testing and Development

• React Testing Library
• Vitest
• Jest
• Playwright
• Cypress
• Storybook
• React Developer Tools
• ESLint
• TypeScript

TypeScript has become particularly important in production React development. React does not require it, but typed component props, API results and shared data models make it a common partner.

Create React App, once the standard beginner toolchain, was deprecated for new applications in 2025. The React team now recommends either using a framework or assembling an application with build tools such as Vite, Parcel or Rsbuild [5].

Is Next.js the Most Common React Framework?

Yes. As of 2026, Next.js is the most common full-stack React framework and the framework most closely associated with modern server-oriented React.

It supplies:

• File-system routing
• Server and Client Components
• Server-side rendering
• Static generation
• Streaming
• Server Functions and Actions
• Route handlers
• Image and font optimization
• Caching and revalidation
• Integrated production builds

Its popularity gives Next.js considerable influence over how developers perceive React. This creates an important distinction: React technologies and Next.js policies are not identical.

For example:

• Suspense is React.
• Transitions are React.
• Hydration is a general React DOM concern.
• Server Components are a React architecture requiring framework integration.
• cache() is a React API for Server Components.
• The Full Route Cache, Router Cache, revalidatePath and "use cache" behavior are Next.js concepts.

A discussion of “React caching” can therefore become misleading if it is actually describing one version or configuration of Next.js.

Next.js is dominant, but React does not require it. Vite with React remains a major choice for dashboards, client-heavy applications and systems with separate backends.

Notable Production Uses of React

React’s production history includes some of the technology industry’s most recognizable services.

Facebook and Instagram

Facebook created React for its own complex interfaces, while Instagram became its major early proving ground. Meta continues using React across major web surfaces and React Native across mobile products.

Netflix

Netflix documented its adoption of React for its website, playback interface and television experiences. Its engineers valued React’s predictable component model and the ability for more developers to work within a familiar architecture [6].

Netflix’s adoption also demonstrated that React could be used outside a conventional browser website. The company integrated React into specialized television environments with custom rendering and performance requirements.

Spotify

Spotify uses React across internal tools and developer infrastructure. Its Backstage developer portal and associated plugins are built around React and TypeScript.

A 2026 Spotify engineering report describes its Release Manager Dashboard as a production Backstage plugin written with React and TypeScript [7].

Microsoft

Microsoft maintains major React-based tools and component libraries. Fluent UI provides React components used across Microsoft experiences, while Microsoft is also a founding member of the React Foundation [3].

Other Production Environments

React has been publicly associated with products and engineering systems at companies including:

• Airbnb
• Atlassian
• Dropbox
• Shopify
• Uber
• Discord
• Reddit

Exact technology stacks change over time, and large companies rarely use only one frontend technology. A company described as a “React user” may use React for one product, an internal system or part of a page rather than its entire platform.

How Much Production React Exists Without Next.js?

No measurement can provide an exact answer.

Technology-detection services can inspect public pages, but they cannot reliably observe:

• Authenticated SaaS applications
• Corporate dashboards
• Banking and healthcare portals
• Private internal tools
• React embedded in only one part of a page
• Custom bundles with obscured framework signatures
• Desktop and mobile React applications
• The original build tool after assets are compiled

BuiltWith currently reports approximately 24.4 million live websites using React and approximately 4.44 million live websites using Next.js [8].

These figures cannot simply be subtracted because the service’s React and Next.js detection categories are not necessarily equivalent. Websites, subdomains, partial React implementations and compiled framework signatures can be counted differently.

Nevertheless, the measurements strongly indicate that the publicly detectable React population is substantially larger than the detectable Next.js population.

The unseen non-Next.js population is likely especially large in enterprise software. For many years, a standard React architecture looked like this:

React single-page application ↓ REST or GraphQL API ↓ Node, Java, .NET, Python, Ruby, PHP or Go backend

Millions of applications were also created with:

• Create React App
• Custom Webpack configurations
• Vite
• Parcel
• React Router
• Independent frontend and backend deployments
• React embedded within existing server-rendered systems

Companies do not rewrite successful production systems simply because a newer framework becomes popular.

The safest conclusion is:

Next.js dominates the visible full-stack React-framework market, but a vast amount of production React continues to run without Next.js—and private enterprise applications make that amount impossible to count accurately.

React’s Forward Direction

React’s direction in 2026 is moving along several connected paths.

From Manual Optimization to Compilation

React Compiler represents a move away from expecting developers to apply memoization manually.

If the compiler can safely optimize ordinary component code, developers can concentrate on application behavior while tooling handles more rendering-performance decisions [4].

This could reduce the need for:

• useMemo
• useCallback
• React.memo
• Manual dependency optimization
• Premature rendering-performance work

The compiler does not eliminate the need to understand React rendering, but it may reduce how frequently developers must intervene manually.

From Client-Only Rendering to Server Coordination

React is increasingly designed as an architecture spanning client and server:

• Server Components
• Server Functions
• Actions
• Streaming server rendering
• Suspense boundaries
• Selective hydration
• Partial prerendering
• Cache lifetimes

This can reduce client-side JavaScript and allow content to arrive progressively. It also makes advanced React applications more dependent on framework, bundler and server integration.

That direction remains controversial. React still has an enormous client-rendered installed base, while some of its most prominent new capabilities are most useful through frameworks such as Next.js.

More Explicit Scheduling of User Experiences

Transitions, Suspense and Activity let React distinguish visible urgent work from work that can be delayed, prepared in the background or kept hidden.

The goal is no longer simply to render the correct result. React increasingly attempts to coordinate when each result should appear and how the interface should behave while work is incomplete.

Framework-First Application Development

The retirement of Create React App reflects an acknowledgment that a production application requires more than a component library.

The React team now encourages frameworks for new applications while preserving a build-tool route for projects where a full framework is unnecessary [5].

This creates two major development paths:

1. Use a full React framework such as Next.js.
2. Build a client-oriented application with React, Vite and selected ecosystem tools.

Continued Web-and-Native Development

React Native, Expo and shared component logic continue moving React toward a broader cross-platform model.

React’s promise is not necessarily “write identical UI code everywhere.” It is the ability to reuse a programming model, architectural knowledge and selected application logic across platforms.

Independent Governance

The React Foundation may broaden React’s direction beyond Meta’s immediate product requirements.

With Amazon, Microsoft, Vercel, Expo and other ecosystem organizations participating, React is entering a more formally shared phase of its development [3].

React’s Unresolved Question

React succeeded because it made one difficult problem easier: keeping an interactive interface consistent with changing application state.

Its modern challenge is different. React must balance:

• A small, adoptable UI library
• A full client-and-server architecture
• Compatibility with millions of existing applications
• Advanced framework integrations
• Better performance without greater cognitive overhead
• Innovation without allowing Next.js to become synonymous with React itself

React’s future may depend on whether its compiler, server features and framework integrations make application development genuinely simpler—or merely relocate complexity into more invisible layers.

Conclusion

React began as Jordan Walke’s response to the difficulty of maintaining Facebook’s rapidly changing interfaces.

Influenced by functional programming, Facebook’s BoltJS experience and XHP’s component-like markup, React proposed that developers should describe the desired interface and allow the library to reconcile changes.

That model reshaped frontend development.

By 2026, React is no longer simply a browser-rendering library owned by Facebook. It supports web and native interfaces, anchors an enormous ecosystem, powers millions of public and private applications and now resides within an independent Linux Foundation-hosted organization.

Next.js has become React’s dominant full-stack framework, but it does not represent all React development. A vast production population still uses React with Vite, custom toolchains, separate backends and enterprise platforms that may never require Next.js.

React’s next era is centered on compilation, server coordination, streaming, intelligent scheduling and multi-company governance.

The question is no longer whether React changed user-interface development. It is whether React can continue changing it without losing the comparative simplicity that made developers adopt it in the first place.