React's own documentation still describes it as a library for web and native user interfaces, now at release 19.2. What has accumulated around that library over the past two years is dense enough to change what a React developer can actually reach without ever leaving the ecosystem.
A developer today can move through several layers while staying inside a broadly coherent TypeScript and JavaScript environment: application frameworks, content platforms, commerce platforms, and the shared tooling underneath all of them.
That density doesn't make React the correct choice for every project. A team already invested in Vue and Nuxt, Laravel, Symfony, Rails, or .NET has little reason to move for its own sake, and plenty of major platforms — Sanity, Contentful, Directus, Shopify's APIs — are deliberately frontend-agnostic and work perfectly well inside a React architecture without becoming React-native platforms themselves. What follows is an argument about ecosystem density and technical continuity, not a case for React as a universal answer.
The clearest illustration of how far that density actually goes starts with a single CMS.
Payload shows how far the convergence goes
Payload announced Payload 3.0 on November 19, 2024, rebuilding the platform to install directly into a Next.js application. The admin panel and HTTP layer now run on Next.js itself, and Payload describes itself today as a Next.js-native CMS and application framework.
A traditional setup connects a frontend framework to an external CMS over an API boundary. Payload's model folds the CMS into the application itself: frontend, server, admin, authentication, access control, and database all sit inside the same Next.js codebase, and the Admin Panel can be extended with ordinary React components. If you're weighing where to actually run that combined stack, the guide to self-hosting Payload CMS with Next.js 16 covers the deployment and CI side in detail.
Payload's ownership changed in mid-2025, when Figma acquired the company. Payload Cloud, the managed hosting product, paused new signups while the team's attention shifted toward what Figma has since described publicly as a CMS built into its own design tooling. The self-hosted, MIT-licensed core is unaffected by the acquisition, and the acquisition itself supports the argument here as much as it complicates it: Figma's stated reason for buying Payload was closing the gap between a Figma design file and the code and content that ship it, which is the same architectural convergence this piece is describing, approached from the design side instead of the framework side.
The broader point extends past Payload. React is increasingly present on both sides of a typical business system — the customer-facing application and the administrative application that manages it — powered by the same rendering model, the same language, and often the same repository.
The framework layer is competitive again
Framework choice inside the React ecosystem currently has three live threads worth tracking.
Next.js remains the default. Vercel's own documentation describes it as a React framework for full-stack web applications, and the current major version, Next.js 16, is what most production teams are running or migrating toward. The App Router, Server Components, and the caching model are already documented at length elsewhere and don't need retreading here. What matters for this piece is Next.js's structural role: it's the framework that made full-stack React application development the default starting point, and the version of React application development a new hire is most likely to already know. Teams deciding where to run it beyond Vercel can find the tradeoffs laid out in the Next.js 16 self-hosted alternatives guide.
TanStack Start is the most credible challenger to that default, and it's worth being precise about what stage it's actually at. As of mid-2026, TanStack Start sits at Release Candidate: the TanStack team describes it as feature-complete with a stable API, built around TanStack Router with server-side rendering, streaming, and server functions layered on top. It doesn't have anything close to Next.js's installed base, and treating it as a drop-in replacement would misstate where it stands. What makes it worth tracking is architectural: it offers a client-first mental model as a genuine alternative to Next.js's server-first defaults, developed inside a TanStack ecosystem — Query, Table, Form, Router — that already has years of independent production use. Some of the early performance claims made for Start have narrowed since Next.js 16 shipped its own optimization work, a reminder that benchmark-driven arguments in this space have a short shelf life. The architectural difference is the more durable reason to keep watching it.
React Router rounds out the framework layer, now on v8 with a full Framework Mode running alongside its existing Data and Declarative modes. Most of the lineage developers associate with the old React-based Remix framework lives here now. The Remix name today refers to a separate project outside React. React Router carries forward the framework patterns developers used to reach for Remix to get.
Payload, Medusa, and Vendure: React as the extension layer
Framework choice is the layer developers argue about most. Payload, Medusa, and Vendure sit one layer above it, and that's where business primitives — content models, product catalogs, order workflows — get put behind a React and TypeScript extension surface a team can actually build a business around.
Payload covers content management, digital asset management, content operations, and general application-backend work, built on TypeScript, running on Next.js, with a React admin and a database layer underneath. Its Admin Panel supports custom React components directly, so the skills a developer builds customizing a Payload admin transfer to any other React codebase, not only to Payload.
Medusa covers commerce: B2B, marketplaces, order workflows, and custom commerce applications. Medusa 2, released in October 2024, was a full architectural rewrite built specifically as a foundation for that kind of customization. Its administration layer is React throughout — Medusa UI is a React implementation of the platform's design system, custom Admin routes are ordinary React components, and the Admin dashboard runs on React Router internally, currently a version behind the React Router release covered above. That's a normal amount of lag for a platform absorbing a major dependency, not a sign the project has stalled.
Vendure covers similar commerce ground — B2B, catalog, orders, promotions, custom commerce logic — and made the same architectural bet Medusa did. Vendure replaced its original Angular-based admin interface with a React-based Dashboard, and its extension system runs on TypeScript throughout.
The pattern across all three is consistent: business primitives, extended through TypeScript, administered through React, wired into application-specific logic a development team writes itself rather than configures through a settings panel. The primitives differ — content collections are not order workflows, and no one should treat the jump from a CMS to a commerce platform as a rebrand of the same admin panel. The extension mechanism, the component model, and a meaningful share of the surrounding tooling stay consistent across all three platforms. That's a different kind of ecosystem leverage than knowing how to theme three unrelated page builders, and a more durable one than any single framework benchmark.
Where the React ecosystem ends
The term "React ecosystem" gets used loosely enough that it's worth drawing an explicit line here.
Payload, Medusa, and Vendure are platforms deeply implemented in React and TypeScript: their extension systems are React, their admin interfaces are React, and building on them is inseparable from writing React and TypeScript code.
Sanity, Contentful, Directus, and Shopify's APIs sit in a different category. Each can be consumed from a React application without difficulty, and each ships a Next.js SDK or equivalent, but none of them is a React platform in the sense described above — their extension surfaces, admin interfaces, and internal architectures are independent of React. A Next.js SDK signals a connector layer, separate from the shared implementation that defines Payload, Medusa, and Vendure.
Shopify sits in a genuinely nuanced middle position. Hydrogen provides an explicitly React-oriented storefront path for Shopify. Shopify's broader commerce platform stays agnostic about what renders the frontend, regardless of which storefront a merchant chooses. That distinction matters for a reason beyond taxonomy: the skills that transfer between Payload, Medusa, and Vendure are implementation skills — admin extension patterns, TypeScript conventions, React component architecture — and those skills don't automatically transfer to a platform whose React SDK is a fetch wrapper around a REST API.
Why ecosystem density matters
Ecosystem density matters because of what accumulates in a developer's head across projects. The value shows up in the second and third engagement more than the first: familiar TypeScript conventions, a familiar admin extension model, and a familiar deployment story mean less relearning each time a new project starts.
A developer moving between Payload, Medusa, and Vendure projects still has real learning ahead of them each time — the data models, the domain concepts, and the specific extension APIs differ enough that no engagement is a rebrand of the last one. What carries over is everything underneath the domain-specific layer: TypeScript conventions, Node.js and JavaScript runtime behavior, React component and admin-customization patterns, PostgreSQL schema and query experience, authentication and permission modeling, background job handling, and the deployment and integration architecture around all of it.
For a service provider, ecosystem density means specialization doesn't have to mean solving exactly one type of business problem. A TypeScript-oriented practice can move between content operations, commerce, and custom application work while carrying most of its underlying engineering knowledge forward from one engagement to the next. Whether that translates into better margins, faster delivery, or higher win rates is a separate question with its own evidence requirements, and it stays outside the scope of this piece.
React's position in 2026
React remains, at its core, exactly what its own documentation says: a library for web and native user interfaces, currently at release 19.2. Around that library now sits a mature full-stack framework, a credible framework alternative built on a different architecture, and a growing set of business platforms that treat React as a native extension language.
That gives the ecosystem an unusual amount of vertical depth for something that started as a UI library — interface, application framework, business platform, custom business logic, and the database and infrastructure layer underneath, largely reachable without leaving TypeScript.
The significance sits in that continuity. A developer who starts in React component work can move considerably further into the application stack, building admin extensions, custom workflows, and full business systems, while carrying forward a large share of the same technical vocabulary, tooling, and conventions the whole way through.
Versions referenced: React 19.2, Next.js 16.3, TanStack Start (Release Candidate), React Router 8. Last checked against current release notes in August 2026.
