One STRUCTURE. Any SKIN. The RENDERER always fits them together.
This is a working demo, not a framework. A STRUCTURE describes what a small app is — its components, hierarchy and flows — with no styling at all. A SKIN is a portable token set plus a layout preference. The RENDERER combines the two live, in your browser, and never leaves a component unrendered.
Structure is built by Konomi — a semantic-schema system for describing what a UI is, independent of how it looks (concept by Thomas Frumkin). Everything below runs locally: no network calls, no accounts, nothing leaves this page.
Explainer structure, skin, renderer — in plain terms
What a thing is
A tree of components — navigation, conversation, data-view, panel-grid, form — with a hierarchy, data-bindings between them, and named flows describing how one component's event affects another. No color, no fixed layout, no styling. Just facts about the app.
How it looks and feels
A portable JSON file: design tokens (color, font, spacing, radii, elevation, motion), a layout preference (density, mode, nav style, panel order), and a component-map — for each component type, which style variant to use. You own a skin. You can export it, hand it to someone else, and import theirs.
What makes it real
Takes a structure and a skin, looks up each component's type in the skin's component-map, and renders that variant with the skin's tokens and layout. If a skin doesn't define a type, the renderer falls back to the base skin's rendering of that type — restyled, never removed.
Structure the sample app's schema — edit it and re-render
This JSON is the whole app: one navigation, one panel-grid of stat cards, one data-view, one conversation, one form — arranged in a hierarchy, plus two flows (a nav selection that highlights a section, and a form submit that posts into the conversation). Edit it, then Apply.
Skin gallery pick, tweak, export, import
Renderer structure × skin, live
Totality self-test a skin restyles, it never removes function
For every component type, this strips it from a copy of the current skin two ways — deleting its entry, and pointing it at a variant that doesn't exist — then renders the sample structure off-screen and checks the component still rendered with real content, via the base skin's fallback. It re-runs automatically whenever the structure or skin changes.
Honest limits what this demo is not
- This is a demo of the split, not a full design system: 5 component types, a handful of style variants each, 5 skins. A real version would need many more of both.
- The renderer's fallback guarantees a component keeps rendering and stays interactive — it does not guarantee the fallback style looks intentional next to the rest of a very different skin. That is a real trade-off of "restyle, never remove."
- Layout arrangement follows a skin's declared panel order and nav style; it does not do general-purpose constraint layout or resize components to fit arbitrary content.
- The conversation panel's replies are scripted demo text, not a live model — there is no backend here at all, by design.
- Tweaking the accent color does not recompute a matching accent-text contrast color; very light or dark custom accents can reduce readability.
- Imported skins are trusted as data (tokens/layout/component-map only) and are not validated against a full schema — malformed values may render oddly rather than being rejected outright.