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.
Related
ui-framework · agent-ready-ui · astryx · terminal-ui · flutter · flutter-3-44