Synthesis — UI Frameworks

The evolving thesis. This spoke was spun out on 2026-07-10 to give a home to a class of sources that kept arriving with nowhere to route: application-level UI frameworks, component libraries, and design systems. Two of them — a terminal-UI core (opentui) and a web design system (astryx) — had been parked in the hub _inbox; when a third UI-library stray would have made three, the router surfaced the spin-out and the human approved seeding the spoke with these two. (The HTTP-client stray, Ky, stayed parked: it’s a runtime library but not UI.)

Why this is a spoke — the negative-space origin

The founding fact is a boundary, not a topic the family already loved. These sources were repeatedly held out of two neighbors:

• Not dev-tooling-wiki — that spoke owns build/version/ship-software infrastructure (compilers, VCS, bundlers). An application-level UI/rendering library is a runtime dependency, not build infra (the Ky precedent).
• Not agentic-tooling-wiki — that spoke owns agent machinery and the generative-UI-output corner (agents emitting UI). A UI toolkit an agent merely builds with is not agent-building tooling. So the spoke is defined by what it is: the UI/component/rendering layer itself — the toolkit you build an interface with, on any surface.

Current thesis

1. One architecture, many surfaces

The founding pair look unrelated — a Zig terminal core vs. a Meta web design system — but they’re two rungs of one stack: a rendering core → reconciler → framework → design system. opentui exposes the lower rungs explicitly (native Zig core + C ABI, with React/Solid reconcilers on top), proving the declarative-components-over-a-render-core model isn’t web-specific — the same React mental model drives a terminal. astryx occupies the top rung: it doesn’t render anything new, it’s an opinionated, themed component + design-token library on top of React. That OpenTUI can also render its component tree to a browser via WebGPU is the sharp version of the claim: the surface is becoming a swappable back-end for a single UI description (terminal, GPU-canvas, DOM), so “terminal UI” and “web UI” are converging toolkits, not separate disciplines.

flutter (2026-07-16) is the native/mobile rung the founding pair lacked, and it pushes the surface-as-swappable-back-end thesis to its limit: rather than adapt to each platform’s UI toolkit, Flutter owns the canvas — it renders every pixel itself through its own engine (Skia/Impeller) — so one Dart widget tree paints identically on iOS, Android, web, and desktop. It’s also a clean second instance of the reconciler rung: Flutter’s persistent element tree diffing an immutable widget tree is the same machinery as opentui‘s React/Solid reconcilers, under Flutter’s own names. So the “one architecture, many surfaces” claim now spans terminal ↔ web ↔ native, with three different answers to who owns the pixels (the terminal grid, the DOM, and — Flutter — the framework itself).

people-in-space (2026-07-26) splits that claim in two. John O’Reilly’s KMP sample runs Compose Multiplatform on Android, Wear OS, desktop and Kotlin/Wasm web from one codebase — four surfaces, one component model, which is the thesis holding. Then it writes the iOS client in SwiftUI by hand over the same shared Kotlin. So the repo that best demonstrates surface-independence also declines it on one platform, and does so without apology.

The distinction that falls out is where the sharing stops, and it’s a second axis alongside “who owns the pixels”:

• flutter — sharing is a framework property. Own the canvas, one widget tree, every surface.
• compose-multiplatform in this project — sharing is a per-platform decision. Data, networking, persistence and DI shared six ways; the UI shared four ways and native on the fifth.

Neither source pays for its choice: a demo app reports no maintenance or performance cost either way. What the sample does establish is that “one description, many surfaces” and “native UI per platform” aren’t rival camps so much as a dial, and a canonical KMP reference (cited by JetBrains’ own docs) sets that dial in the middle.

flutter-3-44 (2026-07-28) prices the canvas bet. A release-level view of Flutter shows what “own every pixel” obliges: Impeller Vulkan cache and sync work, signed-distance functions to fix aliasing, shader-uniform binding by name, and accessibility re-implemented per surface (prefers-reduced-motion on web, aria-description on form errors, iOS motion preferences), all behavior a DOM-based framework inherits for free. Hybrid Composition++ is the admission in the other direction: an opt-in Android path using SurfaceControl to composite native views into the Flutter surface, for the pixels Flutter doesn’t own after all. Owning the canvas isn’t a one-time architectural choice, it’s a standing obligation to rebuild the platform’s behavior on every platform.

1b. The stack’s top rung comes unbundled

flutter-3-44 freezes Material and Cupertino at their final in-framework versions and moves them to standalone material_ui / cupertino_ui packages. Flutter is the one source here that shipped framework and design system fused in a single artifact; astryx was always a layer on React, opentui is the rungs below a design system. So the stack model this spoke proposed gets confirmed from an odd angle — not by a new source fitting it, but by the outlier separating along exactly the seam the model drew, and paying a dependency to do it. The test of whether the split was real: do material_ui and cupertino_ui actually ship on their own cadence, or keep releasing in lockstep with the framework anyway?

2. Agent-ready as the convergent design goal — agent-ready-ui

The non-obvious thing the two share is intent toward AI agents. astryx is “built for how we build now — by people and the agents working alongside them,” with API/docs/CLI designed so humans and agents build identically; opentui ships agent-skill support and is the UI layer of the OpenCode agent. From opposite ends of the stack, both bet that a UI toolkit’s next audience is a coding agent — and that the old virtues (consistency, accessibility, predictable APIs) are exactly what make a toolkit machine-legible. This is the spoke’s live thesis and its seam to ../agentic-tooling-wiki: there, agents emit UI (generative UI, arrow-js/openui); here, the toolkit is the target an agent builds against.

flutter-3-44 moves this from intent to mechanism. Three things a framework did because the builder is an agent: Agentic Hot Reload (an agent connects to a running app and reloads it — handing over the inner loop, not just the source tree), MCP tool definitions consolidated to cut agent token cost (an API-shape decision with a price attached), and packaged Agent Skills for Dart/Flutter — the same unit opentui ships, which makes two independent toolkits converging on skills. The same release also ships GenUI, where agents compose UI at runtime via the A2UI protocol; that half belongs to ../agentic-tooling-wiki, and it’s notable mainly because one vendor is now building both sides of the seam at once.

Open questions

• Does “agent-ready” mean anything beyond good docs + consistent APIs? Partially answered (2026-07-28). flutter-3-44 supplies three non-documentation answers — runtime access via hot reload, a token-cost-driven tool surface, packaged skills. So the category has content. What no source has yet is evidence any of it works: every claim remains the vendor’s, with no measurement of an agent building better against an agent-ready toolkit than a plain one. The question survives in a harder form — is there a number behind this anywhere?
• How far does surface-independence go? OpenTUI renders to terminal and WebGPU. Is a single component description across terminal/web/native the direction, or do surface constraints (the monospace grid, the DOM) keep the toolkits distinct in practice? First real-project data point (2026-07-26): people-in-space goes four surfaces deep with compose-multiplatform and then stops at iOS, where it writes SwiftUI. The limit that showed up first wasn’t a rendering constraint at all — it was a platform whose native toolkit people would rather keep. Sharpened form of the question: is the ceiling on surface-independence technical, or is it that the strongest platform idioms are worth more than the shared code they cost?
• Where’s the middle of the stack? The founding pair are the ends (a low-level core; a high-level design system). flutter now fills the middle rung (a full application UI framework) and adds the native/mobile surface. Plain web component frameworks, CSS frameworks, and web-component libraries are still unsourced — the remaining growth edge. (React meta-frameworks stay out — app frameworks, not UI layers.)
• UI performance as a subject. flutter-performance-200-hours opens it (profile-before-optimizing; cut unnecessary rebuilds) but is a paywalled, partial T4 practitioner post. The reactive-rebuild cost it describes is common to every declarative framework here (the reconciler makes rebuilds cheap; structure makes them frequent) — worth a rigorous source when one lands.

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

1. A number behind “agent-ready.” The category now has content (hot reload, token-costed tool surface, packaged skills) and no evidence any of it works — every claim is the vendor’s. — needs: a T1/T2 measurement of an agent building against an agent-ready toolkit versus a plain one.
2. Where the surface-independence ceiling actually sits. people-in-space stopped at iOS and wrote SwiftUI — a preference, not a rendering limit. — needs: a T2 project report or post-mortem that says what the shared-code ceiling cost, in either direction.
3. The middle of the stack, beyond one framework. flutter fills the application-framework rung alone. — needs: a T1/T2 source on a second full application UI framework, for a comparison rather than a data point.

Coverage edges (added 2026-08-08, at the curator’s request for a wider backlog). These widen what the spoke covers instead of answering an open question above; one ordinary solid source closes any.

4. The web’s incumbent component frameworks. Thirteen pages and not one of React, Vue, Svelte, Solid or Angular — the toolkits nearly every reader has used. The spoke can describe the ends of the stack but cannot place a newcomer against the norm. — needs: official docs plus one independent write-up per framework, starting with React and Svelte.
5. The CSS layer. Tailwind and the utility-class argument, plus CSS-in-JS and the newer native features (container queries, :has()), are absent, so design-system has no styling substrate under it. — needs: T2 documentation or a written-up migration.
6. Web components as the standards-track answer. Lit and the custom-elements story are the one option that outlives framework churn, and the spoke never states the case for or against. — needs: spec-level docs plus a production report.
7. Accessibility as a property of a toolkit. No page treats a11y as something a framework gives you or costs you, which is the property teams are legally obliged to care about. — needs: WCAG-level guidance or an audit comparing toolkits.

Contradictions / tensions

None internal yet — the founding two are complementary rungs of one stack, not competing claims. Both are T2 first-party sources, so the “performance”/“agent-ready” framings are self-reported and await outside evidence.

Cross-spoke adjacency

• ../agentic-tooling-wiki — the generative-UI-output corner (arrow-js, openui) and agent machinery; the agent-ready-ui thread is the seam (agent-emits-UI there vs. UI-toolkit-as-target here).
• ../dev-tooling-wiki — build/ship infrastructure; a UI library is a runtime dependency, not that.
• ../static-site-wiki — SSGs/Jamstack and (excluded) React meta-frameworks; this spoke is the UI/component layer, not the site-build or full-stack-app layer.

Index — UI Frameworks Wiki

Catalog of every page, grouped by schema.org @type. Spine: synthesis (thesis), log.md (history), this file (catalog). Spun out of the hub _inbox ui-frameworks cluster on 2026-07-10 (OpenTUI + Astryx). Some wiki-links resolve to entity nodes in sibling spokes (intentional cross-wiki links, e.g. meta).

DefinedTerm (concepts)

• ui-framework — umbrella: toolkit for building UIs — component model + declarative description + a rendering core; the rendering-core → reconciler → framework → design-system stack · umbrella
• design-system — opinionated layer above a framework: components + design tokens + patterns + theming; consistency/accessibility at scale · concept
• terminal-ui — rendering an interactive UI in the text terminal; a distinct surface reusing web-UI machinery (reconcilers) · concept
• agent-ready-ui — the cross-cutting thread: UI toolkits shaped so AI agents build with them as reliably as humans; partially answered 2026-07-28 (runtime access, token-cost-shaped tool surfaces, packaged skills) · theme

SoftwareApplication

• flutter — Google‘s cross-platform UI framework (Dart; mobile/web/desktop from one codebase); declarative widgets + an element-tree reconciler, and it owns the canvas (renders every pixel via Skia/Impeller); first native/mobile framework here; graph hub to dart + flame-engine
• compose-multiplatform — JetBrains’ Kotlin declarative UI framework off Android: one component model on Android/Wear/desktop/Kotlin-Wasm web — but iOS opts out in people-in-space (hand-written SwiftUI), making the shared/native line a per-platform choice rather than a framework property

SoftwareSourceCode (sources)

• opentui — SST: terminal-UI core — Zig core + C ABI + React/SolidJS reconcilers + WebGPU browser renderer; MIT, ~12.4k★; used by OpenCode/terminal.shop · source · T2 · github.com
• people-in-space — John O’Reilly: the canonical Kotlin Multiplatform sample (Apache-2.0, ~3.4k★, cited by JetBrains’ KMP docs + Google Dev Library) — six targets over one shared Kotlin core (Ktor/SQLDelight/Koin), Compose on four, SwiftUI on iOS · source · T1 · github.com
• astryx — Meta: open-source web design system (150+ React components, design tokens, 7 CSS-var themes, StyleX); powers 13k+ internal apps; “agent-ready” · source · T2 · github.com

BlogPosting (sources)

• flutter-3-44 — Flutter blog: the 3.44 release — Material/Cupertino frozen and moving to standalone material_ui/cupertino_ui packages; Agentic Hot Reload + token-cost-consolidated MCP tools; Impeller SDFs; desktop windowing, with Canonical taking over the desktop embedders · source · T3 · flutter.dev

TechArticle (sources)

• flutter-performance-200-hours — Medium (Chirag Prajapati): a Flutter app-perf post — profile before optimizing, cut unnecessary widget rebuilds, don’t over-optimize; first UI-performance source; paywalled/partial (body past §1 unrecovered) · source · T4 · medium.com

Person

• john-oreilly — author of people-in-space; a personal repo that became a platform vendor’s reference implementation

Organization

• sst — dev-tools group behind SST + the OpenCode agent; maker of OpenTUI
• meta — Meta; maker of Astryx (entity node in ../business-messaging-wiki, cross-linked)

Synthesis

• synthesis — the thesis: one architecture (declarative components over a rendering core) across surfaces (terminal ↔ web ↔ native), converging on agent-ready design

Bridge nodes (live in sibling wikis, linked cross-wiki)

meta (business-messaging-wiki) · google (llm-providers-wiki — maker of flutter) · dart (programming-languages-wiki — Flutter’s language) · flame-engine (game-engines-wiki — built on Flutter)