Why FDS
What Flexa Design System is for, the problem it solves, and how it differs from Tailwind and other CSS frameworks.
FDS treats design as a small, deterministic, accessible data layer — not free-form CSS. A brand is a handful of values; a complete, contrast-checked theme is *derived* from it by pure functions; and every derived value is a semantic token (--fx-*) that can be validated. That is the whole idea, and it is deliberately narrow.
The mission
One core design system, N brand personalities. Instead of maintaining twenty stylesheets, you keep one system and derive every look from a tiny Brand (a primary colour, fonts, a radius feel). The taste, the spacing rhythm, the dark-mode logic and the accessibility floor live in the system — the brand only re-points them.
- Narrow the surface, grow the vocabulary. No arbitrary CSS knob for humans or AI to reach for — you pick from a token vocabulary, and the vocabulary grows on purpose.
- Derive, don't configure. Hover, active, on-primary ink, focus rings, dark overrides — all computed from the brand, never hand-picked per project.
- Accessibility is a gate, not advice. Contrast is measured by the same engine CI runs; an off-system or failing combination is rejected, not warned about.
- One source, every runtime. Tokens emit identical CSS wherever they run, so the same design renders the same in a static site, a React app, or a PHP backend.
The problem it solves
Most design drift is not a taste problem — it is a *source-of-truth* problem. Colours get eyeballed, one-off hex values pile up, a rebrand means find-and-replace across hundreds of files, dark mode is bolted on by hand, and an inaccessible pairing ships because nothing was checking. When design is also generated by tools or AI, free-form CSS output is impossible to trust.
FDS removes the free-form middle. Because a theme is derived from a brand and expressed only in known tokens, a rebrand is one function call, dark mode falls out for free, contrast is enforced up front, and generated design can be gate-checked before it is ever applied.
How it differs from Tailwind (and friends)
Tailwind is a styling *workflow*: utility classes you compose in markup. FDS sits a layer below that — it is the token vocabulary and the derivation/validation around it. They are not competing at the same layer; you can feed FDS variables straight into a Tailwind theme and get both.
| FDS | Tailwind | shadcn/ui | Style Dictionary | |
|---|---|---|---|---|
| What it is | Token system + theme derivation + a11y gates | Utility-class CSS workflow | Copy-in React components | Token build pipeline |
| You author | A tiny brand → derived theme | Classes in your HTML | Component source you own | Token config → outputs |
| Ships to the browser | CSS variables only, no JS | Generated CSS | React + your CSS | Nothing (build tool) |
| Theming a brand | One applyBrand call, derived | Edit the config by hand | Restyle components by hand | Re-run the build |
| Accessibility | Gated (WCAG 2 + APCA + CVD) | Up to you | Up to you | Up to you |
| Dependencies | Zero | A toolchain | React + deps | Node toolchain |
Its closest relatives are Radix Colors (semantic, accessible scales), Open Props (variable-first design values) and Style Dictionary (a token pipeline) — FDS is those three plus built-in brand derivation and WCAG gating, in one dependency-free package. It is *not* a component library: there are no React components and no runtime.
When to reach for FDS
Choose FDS when the hard part is consistency, theming and accessibility at the value layer:
- You need one brand to fan out into many themes deterministically (multi-tenant, white-label, a pack gallery).
- Accessibility must be enforced, not hoped for — contrast is a build gate.
- The same design must render identically across runtimes (static, React, PHP) from a single source.
- Design is produced by tools or AI and must be validated before it is trusted.
- You want semantic CSS variables with zero runtime and no framework lock-in.
Reach for Tailwind, vanilla CSS or a component kit instead when you are hand-authoring one-off UI, want a utility workflow, or need ready-made interactive components — and remember you can still drop FDS tokens underneath any of them. Skip FDS if you specifically want a component library: that is not what this is.
Ready to try it? Follow the Getting started guide, browse the full token vocabulary on the Tokens page, or derive a live theme in the Playground.