Design system
A design system is an opinionated, reusable layer that sits above a UI framework: a coordinated set of components, design tokens (named typography/color/spacing/a11y primitives), patterns (ready-made solutions for tables, forms, wizards, navigation), and theming — so many applications share one consistent, accessible look and behavior instead of each reinventing it.
The distinguishing parts, per astryx (Meta's system, powering 13,000+ internal apps):
- Design tokens / foundations — the shared vocabulary (type, color, layout, accessibility).
- Theming without forking — themes override CSS custom properties, so a brand or mode swaps values, not code (Astryx ships seven).
- Composable components — components expose internal building blocks so teams extend rather than fork.
A design system is a consumer of a framework (Astryx is built on React + StyleX), not a replacement for one — the top rung of the rendering-core → reconciler → framework → design-system stack. Its promise is consistency and accessibility at scale, which is also what makes it legible to agents.
When the framework ships one in the box
flutter is the counter-case: it shipped Material and Cupertino — a Google design system and an
Apple-idiom one — inside the framework download for years, so the top two rungs arrived fused. In
flutter-3-44 both libraries are frozen at their final in-framework versions and moved out to
standalone material_ui / cupertino_ui packages.
That's the separation this page describes arriving late and by subtraction. A bundled design system gets the framework's release cadence and its compatibility promises, which is convenient until the widgets want to move at a different speed than the renderer under them. Unbundling costs a dependency and buys independent versioning — the arrangement astryx had from the start by being built on React rather than shipped with it.
And a third arrangement: no package at all (2026-08-18)
shadcn-ui breaks the pattern this page assumes. Its components are not imported from anywhere — a CLI copies their source into your repository once, and from then on they are your code. Its docs put it as a denial of the category: "This is not a component library. It is how you build your component library."
Line the three up and they trade the same currency in different directions:
| Arrangement | Buys | Costs |
|---|---|---|
| Bundled in the framework (Material, Cupertino pre-flutter-3-44) | compatibility guarantees | release cadence |
| Standalone package on a framework (astryx) | central upgrades across every consumer | a dependency, and its version skew |
| Copied into the consumer (shadcn-ui) | unlimited modification, no version to fight | the upgrade path — a fix reaches nobody |
The third row is in direct tension with the promise at the top of this page. Consistency at scale is enforced by everyone importing the same thing; astryx reaches 13,000+ internal apps because a change to the package is a change to the apps. Copy the code instead and consistency becomes a starting condition that decays from the moment of install. Both projects are widely used, so the disagreement is real rather than one of them being wrong — recorded in synthesis.
Related
ui-framework · agent-ready-ui · astryx · terminal-ui · flutter · flutter-3-44 · shadcn-ui