react: the repository you read is not the package you install

The one example imports react-dom/client, not react

Everything a newcomer needs about the shape of React sits in eight lines on the front page. A component returns markup, a root is created against a DOM node, and render is called once. Read the import line and the project structure becomes obvious: the library and its DOM renderer are separate packages, and the documented starting point is the renderer.

import { createRoot } from 'react-dom/client';

function HelloMessage({ name }) {
  return <div>Hello {name}</div>;
}

const root = createRoot(document.getElementById('container'));
root.render(<HelloMessage name="Taylor" />);

That code renders "Hello Taylor" into the element found by the id `container`. What the snippet leaves out is where the component came from: a component here is an ordinary function that returns a value, and the project states that JSX is not required to use React at all. The consequence for a reader is that the entry barrier is a build step, not the framework.

Three install routes, and the front page names no package

The Installation section is short. React has been designed for gradual adoption from the start, and you can use as little or as much React as you need. That promise is answered with three links rather than commands: Quick Start for a taste, Add React to an Existing Project when you are bolting React onto something that already works, and Create a New React App when you want the full JavaScript toolchain.

No package name, no version, no shell line. Deciding which route to take falls to you, and the front page takes no position on when React is the wrong tool. Starting something new, the toolchain route hides the most from you until later.

A private root package means cloning gets you no react

The root package.json is marked private and declares a workspace over packages/*. Everything a contributor needs sits around that arrangement: yarn.lock for a pinned install, .nvmrc for the Node version, .eslintrc.js and .prettierrc.js for lint and format rules, plus separate Babel configurations for the main build, TypeScript and the React compiler.

{
  "private": true,
  "workspaces": [
    "packages/*"
  ]
}

A private root is never published. The consequence is that the code you read and the code you run are different artifacts: this is where React core is developed, and the bytes that reach your application arrive from the published package. Read the tree to understand the internals, then install the package to actually run them.

JSX is not a language feature, so something must transform it

The front page says JSX is not required to use React, which reads as optional until you look at what the repository needs to compile it. The devDependencies carry @babel/preset-react, @babel/plugin-transform-react-jsx, @babel/plugin-transform-react-jsx-development and @babel/plugin-syntax-jsx, and the root holds babel.config.js, babel.config-ts.js and babel.config-react-compiler.js side by side. There is also a compiler/ directory and a flow-typed/ tree with its own config file.

Three Babel configurations for one repository makes the transform a build concern with several contexts rather than a detail you can skip, and a file that looks like HTML will not run in Node or a browser as written. The consequence: JSX support arrives through your toolchain, so if a compiler step is not already part of your stack, the project asks you to accept one before you have a component worth keeping.

Gradual adoption can leave two rendering systems in one app

Gradual adoption is the project's most repeated promise and its least bounded one. You can add React to an existing project and use as much or as little as you need, which is exactly what makes it easy to begin and hard to finish. Nothing in the README draws a line between the regions React renders and the regions it does not, and nothing describes when a page should hand off to the server rendering it mentions with Node.

The practical result is a codebase carrying two ways of updating the screen, with ownership of each region split between React and whatever the project used before, and reverting to the old path left as a manual exercise. Before adopting React inside an existing application, decide which parts it will own, because the library will not draw that line for you.

The documentation is a different repository on a different domain

This repository is React core, and the documentation is a separate project. The front page points at react.dev for the guide and asks for documentation pull requests to go to github.com/reactjs/react.dev rather than to itself. The reading path runs from Quick Start and a tic-tac-toe tutorial through Thinking in React, Describing the UI, Adding Interactivity, Managing State, and Advanced Guides for escape hatches, ending at the API Reference.

Even the contributing guide sits on legacy.reactjs.org, a different domain from the homepage. The consequence for anyone filing a problem is that a docs typo and a core bug go to different places.

19.3.0 shipped in September while 19.2.8 and 19.1.9 landed together

The release list shows 19.2.9, 19.1.10 and 19.0.9, all dated 2026-10-14, the same day, on three separate minor lines. The last push to the repository was on 2026-10-31 and the default branch is main, so work lands continuously on a branch that is none of those numbered lines.

Three maintenance lines moving on the same day is ordinary for a library with a wide install base, and it puts the version decision back on the reader. CHANGELOG.md at the root is where the differences between lines live, and the front page does not say whether 19.1 still receives fixes or exists only for users who have not upgraded. Read the changelog for your line before pinning anything.

Conduct on code.fb.com, contribution rules on legacy.reactjs.org

Contribution policy is split across three places. The Code of Conduct belongs to Facebook and lives at code.fb.com/codeofconduct, the contributing guide is on legacy.reactjs.org, and the repository itself carries CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, CHANGELOG.md and a MAINTAINERS file at the root. Newcomers are steered to issues carrying the good first issue label, described as bugs with a relatively limited scope.

The code is MIT licensed and the text sits in the LICENSE file at the root, so reuse carries no stated condition beyond that text. The governance documents are separate from the license and from each other. Consequence: before sending a patch, read CONTRIBUTING.md for the process and the conduct rules for behavior, since the front page defers to all of them without summarizing any.

Editorial conclusion

Adopt React when you are writing a new interface or can name the regions of an existing one it will own. Leave it alone if you need a router, a data layer or a build toolchain chosen for you, because this repository names none of those. Verify two things before you commit: which of the three installation routes on react.dev matches your situation, and whether 19.2.9 or an older line such as 19.1 is the one your dependencies expect.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes