Choosing a React component library usually comes down to a familiar trade-off. A ready-made system can get an interface running quickly, but its styling decisions may not match the product you are building. A more flexible library gives you control, although you may spend much of your time assembling and maintaining the foundation yourself.
Meta’s Astryx takes a different route. It combines a large collection of React components with a theme system, page templates, documentation and a command-line interface. Its architecture is built around React 19+ and StyleX, while its published components can be styled using familiar approaches such as Tailwind CSS, CSS Modules and plain CSS.
The project has also attracted considerable attention on GitHub. That interest makes sense: Astryx is designed for both developers and AI coding agents, with its API, documentation and CLI intended to work together.
But popularity does not automatically make a design system ready for every production application. Astryx is still in beta, and some parts of its wider package ecosystem remain experimental or canary-only.
This review looks beyond its component count to examine what developers actually get, how much freedom they have over the interface, and where the system needs more maturity before becoming a project’s primary UI foundation.
Quick Summary
- 150+ components: A broad collection of reusable React interface elements with TypeScript support.
- React 19+: React and React DOM 19 or later are required.
- StyleX architecture: Astryx authors its component styles with StyleX but distributes pre-built CSS for consumers.
- Seven themes: Neutral, Butter, Chocolate, Matcha, Stone, Gothic and Y2K provide different starting points.
- Customisation: CSS variables,
classNameoverrides and source swizzling provide different levels of control.- CLI: Component documentation, templates, theme generation, project setup and migration codemods are available through terminal commands.
- MIT licence: The repository and published core package use the MIT licence.
- Beta status: Developers should test accessibility, framework compatibility, performance and migration behaviour before adopting it for a critical application.
What Is Meta Astryx?
Astryx is an open-source React design system developed at Meta and later released publicly. The project describes itself as a system built for modern frontend development, where developers and AI assistants may contribute to the same interface.
According to its maintainers, Astryx developed internally over eight years and became widely used across Meta’s applications. The public project brings that work into a attributable collection of components, themes, templates and development tools.
Its main package is @astryxdesign/core. This provides the React components, theme system and utilities. Separate packages handle the CLI, optional build tooling and ready-made themes.
The distinction matters because Astryx is not just a collection of buttons and cards. It tries to provide a common foundation for building entire interface patterns.
A developer working on a SaaS dashboard, for example, may need more than a button library. They need navigation, forms, filters, tables, dialog, menus, notifications and consistent spacing. Astryx aims to bring these pieces under one set of conventions.
The project is currently marked as beta. Its growing feature set and Meta’s internal experience are encouraging, but neither removes the need for an independent evaluation.
What Does Astryx Include?
1. More Than 150 React Components
Astryx advertises more than 150 accessible, reusable UI components. The collection covers common interface controls as well as larger interaction patterns.
Its component architecture includes elements such as:
- Buttons and icon buttons
- Inputs, text areas and selection controls
- Cards, badges and status indicators
- Dialog, drawers and bottom sheets
- Dropdown menus and popovers
- Tables, lists and navigation components
- Date and time inputs
- Search and filtering interfaces
- Layout and typography elements
For a SaaS product, this range is useful because different screens often depend on the same interaction patterns.
A settings page might use text inputs, selectors, buttons, status messages and dialog. An analytics dashboard might need tables, filters, menus and cards. A team-management interface could use avatars, lists, pagination and confirmation dialog.
Having these components within one system reduces the need to invent a new implementation for every screen.
The deeper question is how much control developers retain when a component does not fit the intended interface. Astryx’s composition and customisation model is particularly relevant here.
2. Accessibility Is Part of the Component Architecture
Astryx describes its components as accessible and provides extensive interaction behavior for common controls.
Accessibility in a component system involves much more than adding an ARIA attribute. A usable dropdown, for instance, needs sensible keyboard interaction, focus handling, disabled states and announcements that make sense to assistive technology.
The repository’s release notes show ongoing work in these areas. Recent changes include improvements to screen-reader announcements, keyboard navigation, touch interactions, disabled controls and reduced-motion behavior.
That is encouraging, especially for developers who would otherwise need to implement these details themselves.
Still, a library’s accessibility claims should not be treated as a guarantee that an entire application will meet accessibility requirements. The surrounding markup, custom content, component combinations and application-specific behavior all matter.
Before production adoption, test the components that appear in your interface with keyboard-only navigation, screen readers, browser zoom and automated accessibility checks.
3. Seven Themes for Different Visual Directions
Astryx includes seven ready-made themes:
| Theme | Design direction |
|---|---|
| Neutral | Muted, minimal appearance |
| Butter | Warm and softer visual treatment |
| Chocolate | Rich, darker colour direction |
| Matcha | Green-inspired palette |
| Stone | Restrained neutral styling |
| Gothic | Darker, more dramatic presentation |
| Y2K | Distinctive retro-inspired aesthetic |
These themes are not separate component libraries. They provide different visual treatments for the same underlying system.
That separation is useful for product teams. A company can start with a theme that comes close to its intended appearance, then adjust the design tokens to match its own identity.
For example, a finance dashboard could begin with a restrained neutral theme. The team could then define its preferred colours, border treatments, radii and typography without rebuilding every individual component.
Theme availability does not mean that every product will look unique immediately. The final appearance still depends on how the theme is configured and how components are arranged within the application.
How Astryx Uses StyleX Without Locking Developers Into It
StyleX is central to Astryx’s internal styling architecture. It is Meta’s CSS-in-JS system, designed around statically extracted styles and predictable styling behavior.
However, developers consuming Astryx do not necessarily need to author their application styles using StyleX.
The library ships pre-built CSS alongside typed React components. According to its documentation, this lets developers import the required stylesheets without configuring a dedicated StyleX build plugin for the standard consumption path.
That is an important distinction.
A design system can use one styling technology internally while allowing applications to retain their existing styling conventions.
Astryx supports className overrides, which means developers can use approaches such as:
- Tailwind CSS
- CSS Modules
- Plain CSS
A team that already has a Tailwind-based application does not have to discard its existing utilities simply because Astryx uses StyleX internally.
There is one detail worth understanding: styling flexibility does not mean every override will behave exactly as expected without checking CSS specificity and cascade layers. Astryx uses named cascade layers for its reset, base styles and theme tokens. The order of its stylesheet imports matters.
For applications using Tailwind, the project also documents a specific layer order and a token bridge that maps Astryx variables to Tailwind utilities.
This is a manageable requirement, but developers should follow the framework-specific setup rather than copying a generic CSS import into an existing application.
Customisation: Themes, CSS Variables and Swizzling
This is one of Astryx’s most interesting areas.
Many component libraries offer customisation through props and theme settings. That works until a product needs behavior or markup that the library does not expose.
Astryx provides three useful levels of control.
Theme-Level Customisation
The theme system uses CSS custom properties to define visual values.
Developers can adjust brand colours, backgrounds, typography, radii, spacing and other design tokens without changing the component source.
This is generally the first approach to try. When the difference is visual rather than structural, changing a theme token is easier to maintain than modifying individual components.
For example, a product team may want:
- A darker page background.
- A different primary action colour.
- More rounded cards.
- Less prominent borders.
- A specific typography scale.
A theme can handle many of these changes centrally.
Component-Level Overrides
When the theme does not provide enough control, developers can use className and their existing CSS approach.
This is useful for small differences in spacing, dimensions or presentation.
It also makes Astryx easier to introduce into an existing codebase. Teams can retain their current styling tools instead of rewriting everything around a new library.
Swizzling: Take Ownership of Component Source
Swizzling is the more substantial option.
Astryx’s CLI can eject a component’s source code into the application, giving developers direct ownership of that implementation.
That matters when a component needs changes that cannot be achieved cleanly through props or CSS.
Imagine a SaaS product with a complex data table. The standard table may handle most requirements, but the product needs a specialised interaction or a different internal composition. Instead of building a replacement from nothing, developers can start from the existing component source and adapt it.
There is a trade-off.
Once you own an ejected component, you also become responsible for its maintenance. Future updates to the original package do not automatically guarantee that your customized implementation will receive the same fixes or improvements.
Swizzling is therefore best reserved for genuine structural requirements, not ordinary colour or spacing changes.
The Astryx CLI: More Than an Installation Helper
Astryx’s command-line interface is a significant part of the system.
The package @astryxdesign/cli provides access to component documentation, templates, theme tooling, project setup and migration utilities.
Some useful commands include:
# See available commands
npx @astryxdesign/cli --help
# Search for a component
npx @astryxdesign/cli search button
# Read component documentation
npx @astryxdesign/cli component Button
# List available page templates
npx @astryxdesign/cli template --list
# Read design token documentation
npx @astryxdesign/cli docs tokens
# Initialise Astryx for an AI-assisted project
npx @astryxdesign/cli initThe init command is particularly interesting for teams using AI coding assistants. It writes an Astryx component reference into project guidance files such as AGENTS.md or CLAUDE.md.
This gives an assistant a more reliable reference for the components, templates and tokens available in the project.
Without that context, a coding assistant may invent props, use the wrong component or recreate functionality that already exists in the library.
The CLI also provides commands for generating themes, ejecting component source and applying migration code mods.
One practical warning: use the scoped package name when invoking the CLI through npx. The repository specifically warns that the unscoped astryx name can resolve to an unrelated npm package when the Astryx CLI is not installed.
Installation: Add Astryx to a React Project
Astryx requires React 19 or later. Its core package lists React and React DOM as peer dependencies, and the documented installation also includes StyleX and a theme package.
For an npm project, install the core packages:
npm install @astryxdesign/core @astryxdesign/theme-neutral @stylexjs/stylexAdd the CLI as a development dependency:
npm install -D @astryxdesign/cliConfigure the Stylesheets
For a standard Next.js setup, Astryx documents three CSS imports:
@import '@astryxdesign/core/reset.css';
@import '@astryxdesign/core/astryx.css';
@import '@astryxdesign/theme-neutral/theme.css';Keep this order. The reset, component styles and theme overrides use separate CSS cascade layers.
Add the Theme Provider
Create a client-side provider:
'use client';
import { Theme } from '@astryxdesign/core/theme';
import { neutralTheme } from '@astryxdesign/theme-neutral/built';
export function Providers({
children,
}: {
children: React.ReactNode;
}) {
return (
<Theme theme={neutralTheme}>
{children}
</Theme>
);
}Wrap the application with this provider through your root layout.
Use a Component
A basic button can be imported directly from its component entry point:
import { Button } from '@astryxdesign/core/Button';
export default function Page() {
return (
<main>
<Button label="Create project" variant="primary" />
</main>
);
}This is a small example of the documented component API. Check the installed version’s component documentation for the available props and variants rather than assuming every component follows the same interface.
Framework and Environment Requirements
Astryx documents setup paths for Next.js, Tailwind CSS, Vite and CDN-based prototypes.
For repository development and contribution, its current instructions specify Node 22+ and pnpm 11. Those contributor requirements should not be confused with the runtime requirements of every consuming application.
If you already have a React 19 application, the standard pre-built CSS approach is relatively straightforward. An older React project will need to address the React version requirement before adopting Astryx.
Page Templates and Component Composition
A component library provides individual building blocks. A design system becomes more valuable when those building blocks can be assembled into common product experiences.
Astryx includes page and block templates for patterns such as dashboards, settings, forms and detail pages.
Its documentation recommends starting with a template when building a complete page, then placing it inside the application’s own navigation and shell structure.
For example:
# Browse available templates
astryx template --list
# Generate a dashboard page
astryx template dashboard
# Generate a settings layout skeleton
astryx template settings --skeletonThis can save time during the early stages of a SaaS project.
A developer building an admin panel does not need to begin with an empty page and manually decide how every section should fit together. A template provides an initial structure that can then be adapted to the product.
The important word is starting point. Generated templates still need product-specific content, responsive checks and interaction testing.
Astryx vs Established React Component Libraries
Astryx enters a mature ecosystem. Developers already have several established options, each with a different approach to design, composition and customisation.
| System | Main approach | What to consider |
|---|---|---|
| Astryx | Integrated design system with themes, templates and CLI | Beta maturity and React 19+ requirement |
| shadcn/ui | Copy and own component source | More responsibility for assembly and maintenance |
| Material UI | Established component framework and design language | Stronger commitment to Material-based conventions |
| Radix UI | Accessible, unstyled primitives | More design and visual implementation work |
| Mantine | Broad React component and hook ecosystem | Its own styling and theming conventions |
This is not a feature-by-feature benchmark. These projects serve different development preferences.
Astryx’s clearest distinction is the combination of a substantial component library, theme packages, source swizzling, ready-made templates and a CLI designed to support both developers and AI assistants.
A team that wants a coherent starting system may appreciate that integration.
A team that prefers to assemble its own design language from low-level primitives may find a more composable primitive library easier to fit into its architecture.
Teams already committed to another design system also need to consider migration costs. Replacing a mature component foundation simply because another project is attracting GitHub stars rarely pays off without a concrete technical reason.
What Developers Should Check Before Production Adoption
Astryx’s beta status is the most important caveat in this review.
The project is active, but developers should distinguish between the packages that are available as stable releases and those still marked experimental or canary-only.
The repository identifies @astryxdesign/lab as an internal experimental package that is not published to npm. Its chart packages, @astryxdesign/charts and @astryxdesign/vega, are published under the @canary dist-tag rather than as stable releases.
That matters if your application depends heavily on data visualization. Do not assume that every component shown in the Storybook or sandbox is part of the stable core package.
Before adopting Astryx for a production application, check the following:
React compatibility: Confirm that your application uses React 19 or later and that all related framework dependencies support the required version.
Component coverage: Build a small representative screen using the components your product actually needs. A total count of 150+ does not tell you whether the system covers your particular workflows.
Accessibility: Test keyboard navigation, screen-reader behavior, focus management and reduced-motion preferences. Do not rely solely on the library’s accessibility description.
Theming and CSS: Verify the cascade order, token overrides and interaction with your existing Tailwind or CSS setup.
Customisation: Test whether ordinary props and CSS overrides are enough before ejecting source through swizzling.
Release stability: Check package versions, change logs, migration instructions and the status of any canary dependencies.
Performance: Test real pages with realistic data, overlays, tables and nested interactions. Do not infer runtime performance from the component count or repository popularity.
Maintenance ownership: Decide who will handle customized components, version upgrades and any regressions introduced by changes.
A small proof of concept is a much better adoption test than immediately migrating an entire application.
Final Verdict: Is Meta Astryx Worth Trying?
Astryx is an interesting addition to the React design system ecosystem because it approaches the problem from several directions at once.
The component collection provides a broad starting point. Seven themes give teams options for establishing a visual direction. StyleX supplies the internal styling architecture, while CSS variables, className overrides and swizzling offer different degrees of customisation.
The CLI adds another layer of value. It makes component documentation, templates and migration tools available directly from the development environment. Its project guidance for AI assistants is also a thoughtful feature for teams that increasingly use agents to generate and modify frontend code.
There is a trade-off, and it should not be ignored. Astryx is still beta. Its ecosystem includes packages that are not stable releases, and the system requires React 19 or later. Developers should also account for the maintenance work that comes with source-level customisation.
For a new React 19 SaaS project, Astryx is worth exploring through a focused prototype. It may be particularly appealing to teams that want a themed component foundation with integrated tooling rather than a collection of unrelated packages.
For an established application with a mature UI system, the decision is less straightforward. Migration should be driven by a clear improvement in maintainability, accessibility or development workflow—not by GitHub momentum alone.
Astryx looks promising because it gives developers more than components. It gives them a way to work with those components, customize them and document the system that surrounds them. Whether it becomes a dependable production foundation will depend on how the project matures beyond beta.