Log — UI Frameworks Wiki

Append-only history. Each entry starts with ## [YYYY-MM-DD] <op> | <title> where <op> is ingest, query, lint, or split, so grep "^## \[" log.md | tail -5 works.

[2026-07-10] split | ui-frameworks-wiki created from _inbox (2 sources)

Spun out at the human’s approval to give application-level UI frameworks / component libraries / design systems a home — a class repeatedly held out of dev-tooling (Ky boundary: runtime UI lib ≠ build infra) and agentic-tooling (OpenTUI precedent: a UI toolkit an agent builds with ≠ agent-building tool). Seeded with the two parked UI-library strays: opentui (SST; Zig-core terminal-UI framework) and astryx (Meta; web design system). Ky stayed parked (js-libraries — an HTTP client, not UI). Founding pages: sources opentui/astryx; concepts ui-framework (umbrella), design-system, terminal-ui, agent-ready-ui (the cross-cutting thread); Organizations sst + cross-wiki meta. Synthesis thesis: one architecture (declarative components over a rendering core) across surfaces (terminal↔web), converging on agent-ready design. _inbox/opentui.md + _inbox/astryx.md deleted.

[2026-07-10] ingest | OpenTUI (SST terminal-UI core)

Founding ingest. opentui (SoftwareSourceCode, T2): native Zig core + C ABI, TypeScript bindings, React & SolidJS reconcilers, Three.js WebGPU browser renderer; MIT ~12.4k★; production at OpenCode/terminal.shop; ships AI-agent skill support. Seeded terminal-ui, ui-framework, agent-ready-ui, maker sst.

[2026-07-10] ingest | Astryx (Meta web design system)

Founding ingest. astryx (SoftwareSourceCode, T2): open-source design system powering 13k+ Meta internal apps — 150+ React components, design tokens, seven CSS-variable themes, StyleX, framework-agnostic styling; “fully customizable” + “agent-ready”. Seeded design-system, reinforced ui-framework/agent-ready-ui; maker cross-linked meta (../business-messaging-wiki).

[2026-07-16] ingest | I Spent 200 Hours Optimizing My Flutter App (Medium, hub-routed, Telegram)

Ingested a Flutter app-performance practitioner post (Chirag Prajapati) → source flutter-performance-200-hours (TechArticle, T4 — Medium member-only; partial ingest: even via the author’s free friend-link only the intro + technique §1 were recoverable, later sections behind the paywall). Recovered substance: thesis = profile before optimizing, fix real bottlenecks not imagined ones, don’t over-optimize; §1 = reduce unnecessary widget rebuilds (rebuilds are how Flutter works; cut the needless ones). Routed here because Flutter is a UI framework and its widget-rebuild model is rendering-internals — the spoke’s core theme. Created the canonical flutter node (SoftwareApplication): Google’s cross-platform UI framework, a textbook rendering-core→reconciler→framework instance (immutable widget tree + persistent element tree = the reconciler, like opentui‘s), notable for owning the canvas (Skia/Impeller renders every pixel) — the extreme of the surface-as-swappable-back-end thesis, and the wiki’s first native/mobile framework + first UI-performance source. Reused cross-wiki google (maker); cross-linked dart (dev-tooling, Flutter’s language) + flame-engine (game-engines, built on Flutter) — Flutter as a 3-spoke graph hub. Author (Chirag Prajapati) deferred (thin T4). Synthesis: Flutter fills the middle rung + native surface + opens UI-performance-as-subject. avoid-ai-writing self-pass (clean). +2 pages, 3 spine files updated.

[2026-07-26] ingest | PeopleInSpace — John O’Reilly’s Kotlin Multiplatform sample (github.com/joreilly/PeopleInSpace)

Routed here by the hub. T1 (the project’s own repo), Apache-2.0, ~3.4k★, and cited in JetBrains’ KMP docs plus Google’s Dev Library — a personal repo doing a platform vendor’s reference-implementation job. New: people-in-space (source), compose-multiplatform (Thing), john-oreilly (entity). Updated: ui-framework (new section — a second axis: how far up the stack sharing goes), flutter (the contrast: framework-property sharing vs per-platform choice), synthesis §1 + the surface-independence open question. The finding: six targets over one shared Kotlin core, Compose Multiplatform on four of them (Android/Wear/desktop/Kotlin-Wasm web) — and SwiftUI by hand on iOS. The repo that best demonstrates surface-independence declines it on one platform. That reframes the spoke’s standing question: the first ceiling on “one description, many surfaces” wasn’t a rendering constraint, it was a platform idiom worth keeping. Dedup: flutter was the nearest page and stays distinct — Flutter owns the canvas everywhere; Compose Multiplatform here shares selectively. No Compose/KMP page existed. Weakness recorded on the page: it’s a demo, not a deployment. No cost is reported for either strategy, and the repo evidences Compose Multiplatform’s targets, not its internals — so the page can’t yet be placed on the rendering-core → reconciler → framework stack. That’s the next source to want. Verify deferred per hub policy (content-only). avoid-ai-writing run.

[2026-07-28] ingest | What’s new in Flutter 3.44 (flutter.dev/blog/whats-new-in-flutter-3-44)

Routed here by the hub. T3 — a first-party release announcement, promotional in framing (leads with download counts and a “500% growth” figure) but authoritative on what shipped. First release-level source in the spoke; dedup found flutter already paged, so this is a new source summary plus a refresh of that node, not a duplicate. New: flutter-3-44 (source, BlogPosting, freshness: volatile). Updated: flutter (two new sections — what the canvas bet costs; agent access to the running app), agent-ready-ui (past-docs section — the standing open question gets a partial answer), design-system (the bundled-design-system counter-case, now unbundling), synthesis §1 + new §1b + §2 + the agent-ready open question, index. Two findings worth the ingest. Material and Cupertino are frozen at their final in-framework versions and move to standalone material_ui/cupertino_ui packages — Flutter was the one source here shipping framework and design system fused, so the spoke’s rendering-core→reconciler→framework→ design-system model gets confirmed by the outlier splitting along exactly that seam. And agent-ready UI acquires mechanism: Agentic Hot Reload hands a coding agent the running app (the inner loop, not the source tree), the MCP tool definitions were consolidated to cut agent token cost, and Dart/Flutter Agent Skills land — the same unit opentui ships, so two independent toolkits now converge on skills. Gap-relevance: answers part of the spoke’s oldest open question. Recorded limit: still no measurement that any of it beats plain docs; the claims are all the vendor’s. Cross-spoke context, not fragmented: GenUI (agents composing UI at runtime, A2UI protocol) belongs to ../agentic-tooling-wiki’s generative-UI-output corner; Genkit Dart / flutter_gemma / LiteRT-LM are model plumbing (llm-providers, llm-inference); the SwiftPM + Gradle 9 toolchain shifts touch dev-tooling via dart. All noted inside the source page rather than split into other spokes. Canonical (new lead maintainer of the Linux/Windows/macOS embedders) mentioned in prose, not paged — third party, not this source’s author/publisher/owner. Verify deferred per hub policy (content-only, no page moves). avoid-ai-writing run.