Skip to content
Airframe

Why Airframe

Airframe is a structural UI design system for humans and AI.

Your framework provides the engine. Airframe provides the structure.

Structure first

Section titled “Structure first”

Most UI tools help you style surfaces or assemble components. Airframe starts earlier: how the UI is organised, named, and constrained before you decorate it.

That is not a brand-new category. It is a different priority. Structure before decoration, so markup stays understandable when humans or AI change it.

What you get

Section titled “What you get”
  • Structure — af-stack, af-inline, af-grid, af-center, af-sidebar (primitives). af-app, af-cover, af-body (shells). Concepts, not one-off flex recipes.
  • Full token layer — colour, space, type, radii, motion. Override --af-* tokens and your brand applies without a rebuild.
  • Readable DOM — af-card, af-btn, af-stack. Read the markup, understand the UI.
  • Accessibility built in — Visible focus, reduced-motion, contrast-minded defaults, RTL-ready patterns. Themes include high-contrast. Aim for WCAG 2.2 AA; your content and choices still matter.
  • Zero runtime JS — CSS-only. Works with any framework, or none.

Same language for humans and AI

Section titled “Same language for humans and AI”

Keeping intent intact is hard. AI can generate markup quickly if patterns are predictable. Humans can keep shipping it if the DOM is readable.

Utility-first markup is cheap for models to emit and hard for people to own:

<div class="flex flex-col gap-4 p-6 bg-white rounded-lg border border-gray-200 shadow-sm">
  <h2 class="text-xl font-semibold mb-2">Title</h2>
  <p class="text-gray-600">Content</p>
</div>

Airframe stays readable:

Title

Content

<div class="af-card">
  <h2 class="af-card__title">Title</h2>
  <p class="af-card__body">Content</p>
</div>

AI can generate either. Humans can maintain the second. Generation rules and MCP live in AI Rules.

One language, any engine

Section titled “One language, any engine”

The markup is the design intent. Frameworks only differ in how they bind class vs className.

<header class="af-inline af-justify-between">
  <h1>Team</h1>
  <button class="af-btn">Invite</button>
</header>

React, Angular, Vue, and HTML consume the same classes. There is no @airframeui/react. That absence is the architecture.

SurfaceWhat staysWhat can change
ApplicationsTokens, layout grammar, pattern lookReact, Angular, Vue, HTML
TeamsOne --af-* sourceSeparate kit packages per engine
AgentsRules, class reference, MCPThe framework they emit

Typed wrappers stay on the engine. Use as much as you need.

Design vs behaviour

Section titled “Design vs behaviour”

Airframe owns look and layout. Native HTML is the default behaviour layer: <button>, <dialog>, <details>, form controls.

Menus, comboboxes, and focus traps need JS. Keep that in your kit or a primitive library. Do not wait for a CSS system to invent a keyboard map.

EngineBehaviour you might sit on Airframe
ReactReact Aria, Base UI, Zag, Radix
AngularCDK, your own FocusTrap, overlay services
VueHeadless UI, Ark, Reka
AnyNative <dialog>, plus a small kit helper

Not a widget kit

Section titled “Not a widget kit”

“Framework-agnostic” usually means one of two products.

Component kitCSS contract (Airframe)
SharesOne widget implementation + bindingsTokens, layout grammar, pattern look
Wins atKeyboard maps, typeahead, focus trapsPage structure, brand, agent contract
Costs youTheir DOM, props, theming APIYou bring JS for rich widgets

A kit that solves widget portability can still leave you with five design systems. A CSS contract will not give you a shared JS keyboard map. Sit the kit on Airframe. Do not replace the grammar with it.

CSS is authored. Catalogs, docs, MCP, ESLint, and IntelliSense are generated from it. Look them up. Do not dump them into a prompt.

Principles

Section titled “Principles”
  1. Structure over styling — Prefer af-stack over flex flex-col gap-4. Names that say what the UI is.
  2. Human-readable in the DOM — If you can read the markup, you can understand the UI. Semantic HTML is the baseline.
  3. Built for humans and AI — Predictable patterns. Same classes in a template a person wrote and in markup an agent generated.
  4. Accessible by default — Not a plugin. A system constraint, with room for you to get the details right.
  5. Framework-agnostic — Engines change. Structure stays.

What Airframe is not

Section titled “What Airframe is not”
  • Not a UI library — No JS widget zoo. Patterns are CSS. Behaviour stays native (<button>, <dialog>, <details>).
  • Not a utility free-for-all — Classes express structure and intent, not every possible CSS property.
  • Not a design system for one brand — Tokens are yours to override. Airframe is the skeleton, not the skin.
  • Not a competitor to your UI kit — Use Airframe as the system, or wrap af-* in <my-button> / <MyButton>. Use as much or as little as you need. Do not paint a second look beside it.
  • Not framework lock-in — No runtime. No proprietary components. Leave when you want; the markup still makes sense.
  • Not magic — Explicit classes, explicit tokens, cascade layers you can see and extend.

Airframe provides structure, not shortcuts.

Section titled “Related”