Astryx Review (feat. shadcn/ui): UI Is Still Hard for Backend Developers

Lately I keep getting stuck whenever the work moves from backend code to UI. Data flow, APIs, authentication, batch jobs, and incident handling feel familiar enough. But making a screen look consistent and usable still feels harder than it should. Our company solution is based on Angular, which makes the feeling even more complicated. Interesting UI tools keep appearing in the React ecosystem, but I cannot simply drop them into the company product.

That is why Meta’s Astryx caught my eye. Its official description is an open source design system that is fully customizable and agent ready. The repository is public as facebook/astryx, and as of July 2026 it had around six thousand GitHub stars. The public packages are also available as @astryxdesign/core, @astryxdesign/cli, and @astryxdesign/theme-neutral.

What Astryx seems to be aiming for

Astryx is not just a collection of buttons and cards. It feels closer to a design system built so that AI coding tools can produce less-wrong UI code. The official Working with AI documentation is direct about this. Instead of letting a model fall back to generic React patterns or invent nonexistent props, the CLI can generate component indexes, rules, and documentation context for the AI tool.

npm install @astryxdesign/core @astryxdesign/theme-neutral @astryxdesign/cli
npx astryx init --features agents

In other words, it is not only for humans reading documentation and assembling components one by one. It tries to let both the developer and the AI agent work from the same design-system rules.

How is it different from shadcn/ui?

shadcn/ui is already familiar to many frontend developers. Its docs say it is not a component library, but a way to build your own component library. Instead of installing a traditional UI package and importing components from it, you bring the component code into your project and own it.

Astryx feels closer to installing and using a component package such as @astryxdesign/core. Around that core package, it adds design tokens, themes, StyleX, Tailwind bridge support, CLI tools, and agent documentation.

Area	Astryx	shadcn/ui
Nature	Meta’s open source React design system	Copy-and-own UI component distribution platform
Usage	Install `@astryxdesign/core` and import components	Add component source code into the project through the CLI
AI support	Agent docs, JSON API, CLI-generated context	MCP, registry, v0, and AI-friendly workflows
Customization	Tokens, themes, StyleX, Tailwind, className	Own the code and edit directly
Philosophy	Consistent design system plus agent friendliness	Open code that becomes your own component library
Current limitation for me	React-first. I do not see direct Angular support.	Also mainly React-focused, not directly useful for Angular.

What I like about Astryx

From a backend developer’s point of view, the best part is that Astryx explicitly thinks about the context given to AI. When I ask an AI tool to build a screen, it often writes JSX that looks plausible but does not match the real design-system rules, or it invents props that do not exist. Astryx seems to treat that as a first-class problem.

The component range is also interesting. It is not only buttons, cards, forms, and menus. It also includes chat-related components, App Shell, templates, themes, and token documentation. For admin screens, AI chat UI, and settings pages, that is more interesting than a simple landing-page kit.

Where the caution starts

The caution is also clear. Astryx still feels like a beta-stage design system. The GitHub issues are active, npm versions are moving quickly, and I would want to watch API stability, long-term maintenance, and design policy before putting it into a company product.

The most useful real-world signal I found was a GitHub issue about migrating an existing React + Vite + Tailwind/shadcn-style dashboard toward Astryx, or the earlier XDS lineage. Since I am also changing a React project, this part felt especially relevant.

That migration record showed traces of the transition from @xds/* naming to the public @astryxdesign/* packages. There was early integration cost around package installation, Git-based dependencies, CLI execution, and workspace package references. Later comments show that the migration continued by adding pieces such as XDSTheme, XDSLinkProvider, XDSAppShell, XDSTopNav, and XDSSideNav.

That does not make Astryx bad. It simply means that incremental adoption into an existing React project is not automatically easy. Starting a new project in the prescribed way would probably be cleaner. But if a screen is already built in a Tailwind or shadcn/ui style, the integration cost needs to be considered first.

And the biggest limitation for my company work is still the React focus. Official examples revolve around Next.js, Vite, StyleX, and Tailwind. For our Angular-based solution, the components are not something I can just bring in and use. The design tokens and screen-structure ideas are useful, but direct adoption looks difficult.

The part I still find disappointing

Honestly, the Angular gap is the part that disappoints me most. Our company solution is Angular-based, so even when I see a tool like this and think it looks useful, I cannot just say, “let’s try it tomorrow.” Even in React projects, existing-app migration can involve naming transitions, packaging, CLI setup, and theme wrappers. In Angular, that wall is naturally higher.

As a backend-focused developer, the hard part is not just styling details. It is deciding which component should be used in which screen, how the layout should stay consistent, and how to avoid making a UI that only looks okay in one place. If Astryx had Angular support, I would have been much more excited. Even without Angular components, I would like to see an easier way to bring design tokens and AI-readable UI rules into Angular projects.

The direction is still interesting. UI tools are moving beyond “here are pretty components.” They are starting to provide the rules that AI agents need when generating screens. If shadcn/ui made the idea of owning copied component code popular, Astryx feels closer to making a design system understandable to AI.

Conclusion

I do not think Astryx is something I can immediately apply to our Angular company solution. That is disappointing. But as a backend developer who keeps getting stuck in UI work, it is still an important signal.

What I want is not a flashy UI builder. I want clear guidance: use this component for this kind of screen, lay it out this way, and follow these rules. Astryx looks like an attempt to deliver that guidance not only to people, but also to AI agents.

For now, I will remember it less as a tool to adopt immediately and more as a reference point for React-based new projects and AI-assisted UI generation. I hope Angular eventually gets stronger tooling in this direction too. Backend developers would like to get lost less often in UI work.

References

Original Korean version: This article is based on the Korean version and lightly adapted for English readers. Read the original Korean post.
Please show some love to Korean, too.