React handles interface state, while the application shell stays yours
React turns application state into components and updates the rendered interface when that state changes. The public API centers on components, props, hooks, and roots. JSX is optional, although it is the normal authoring style shown in the documentation. That model works for a single interactive panel inside an existing page, a browser application, server-rendered output through a framework, or native interfaces through React Native.
The boundary matters more than the feature list. React does not choose routing, data access, authentication, deployment, or a directory layout for you. Its installation guide recommends a framework for new applications, while the README also documents gradual adoption. That makes React flexible inside an established engineering organization. It can leave a new team comparing several packages before the first product screen exists.
The ecosystem is large because React leaves major choices outside core
A React component is portable across many React-based stacks, and the library has enough adoption that design systems, test tools, editors, and hosting platforms usually account for it. GitHub showed 247,905 stars when we fetched the repository. Popularity does not prove fit, but it lowers hiring and integration risk for teams that expect the same interface code to live for years.
The cost appears in decision count. A production app commonly needs a framework or separate answers for navigation, server rendering, forms, caching, and requests. React's own docs make that division clear. Teams with strong platform conventions can treat the library as a stable rendering layer. A two-person project may spend more time selecting and joining supporting parts than it would with a more directed framework.
What happened when we ran it
Our run at commit 6c3bd60 installed 1,800 Yarn packages in 203 seconds. Dependencies occupied 1,358 MB, compared with a 40.4 MB checkout containing 7,206 files and roughly 827,740 source lines. Installation succeeded in the fresh Debian container with 3 CPUs and 8 GB of RAM. Those figures describe work on React itself, not adding the published react package to an application.
The source build failed after 8 seconds. Its final log showed the Google Closure Compiler command trying to launch Java, followed by spawn java ENOENT and the direct question, Is java in the path? Java was absent from this Node 22 image. The evidence supports one narrow conclusion: a fresh Node-only container did not contain every system tool needed by this build path.
Tests continued for 233 seconds and finished with exit code 1. Jest reported 6,925 passed, 9 failed, and 23 skipped out of 6,957 tests. All 302 snapshots passed. The failures came from React Flight Turbopack DOM Node, React Cache, and React Multi Child Text suites. The log tail names those suites but does not show enough detail to assign a cause.
Source contribution needs more machinery than application use
The checkout is a Yarn 1 workspace monorepo rather than a typical app created from a starter. Its package scripts wrap custom Jest, Rollup, Flow, lint, release, and error-code tooling. Our scan found 23 CI workflow files and no Dockerfile. It also found no top-level tests directory because tests sit alongside package code. Contributors should follow repository scripts instead of applying assumptions from a conventional Node project.
For application developers, the normal route is far lighter. Install the released packages or let a recommended framework manage them, then use the React documentation for components and hooks. No API credential is required. That difference explains why millions of developers can use React without ever installing 1,800 repository dependencies, running the internal release-channel builds, or supplying Java to the Closure Compiler.
React 19.2.8 is current, and open reports still matter
GitHub recorded a push on August 26, 2026, and the latest release was React 19.2.8, published July 21, 2026. The repository showed 1,274 combined issues and pull requests. That combined number is evidence of activity and scale, not a count of confirmed defects. The latest release notes describe a decoding performance improvement for React Server Components.
Current reports are still worth checking against an application's unusual edges. Issue 34663 describes custom elements receiving common attributes differently from native elements, including aria-invalid. Issue 37374 supplies a reproduction where a re-entrant act() call leaves updates pending in tests on React 19.2.8. Both reports were open when fetched, so teams using custom elements or nested testing-library behavior should reproduce their own case before treating either report as resolved.
React is the safe default only when its open architecture helps
React earns a place on a shortlist for an interactive product that needs a deep component ecosystem, broad staffing options, and freedom to pick its surrounding stack. The MIT license, current push activity, React 19.2.8 release, and 23 CI workflows support a high maturity score. The 6,925 passing tests in our sandbox also show substantial exercised behavior, even though the complete suite did not pass.
The source repository is a poor first contribution target for anyone expecting a small JavaScript package. Our 1,358 MB dependency footprint, missing-Java build failure, and 233-second failed test run make that plain. Application adoption is a separate decision and usually much easier. Use React when your team values its ecosystem enough to own the remaining architecture choices; otherwise, test a narrower library or a more directed framework before committing.