Comparisons
.gui vs XAML, QML, and GTK .ui: interchange, not a runtime
The most common reaction to .gui is "isn’t this just XAML?" It has the same markup shape and a different job: those are UI languages bound to a runtime; .gui is a portable target that can emit them.
Show a markup-based UI format to enough engineers and someone will say "so… XAML?", and they’re not wrong to notice the resemblance. XAML, QML, GTK’s .ui, JavaFX FXML, and .gui all describe interfaces as declarative, tag-based markup. The XKCD "now there are 15 competing standards" reflex is the honest thing to feel here. The difference isn’t syntax; it’s what the file is for.
XAML/QML/.ui are runtimes; .gui is an interchange target
XAML is a UI language for Microsoft’s frameworks (WPF, WinUI, MAUI); QML is Qt’s; GTK .ui is GTK’s; FXML is JavaFX’s. Each is bound to its own runtime and toolchain: a XAML file expects the .NET layout engine, data-binding system, and control library to be present, and it is meaningless without them. That binding is a feature for building an app on that stack and a wall for moving a design off it. .gui deliberately has no runtime of its own: it’s not a framework, it runs no logic (.gui vs HTML), and it isn’t meant to be the application you ship.
The mental model is one layer up. Think of .gui as sitting above XAML/SwiftUI/Compose the way SVG sits above a specific rendering engine: a portable, human-readable representation of a UI that can be previewed, edited, versioned, generated by AI, and then converted into any of those runtime languages, rather than competing with them (What problem does .gui solve?). Asking "XAML or .gui?" is a category error; the intended answer is ".gui, then generate the XAML."
Where the analogy to XAML breaks down
| XAML / QML / .ui | .gui | |
|---|---|---|
| Primary purpose | Author an app on one framework | Exchange a design between tools, AI, and platforms |
| Runtime | Bound to one (.NET, Qt, GTK) | None: converted to a target |
| Logic / bindings | Yes: code-behind, data binding | No logic; static by design |
| Portability across stacks | Not a goal | The entire goal |
| Meant to ship as-is | Yes | No: it’s the source, not the product |
"But MAUI already runs XAML cross-platform" is the strongest version of the objection. It’s true, and it proves the point rather than refuting it: MAUI makes XAML portable across Microsoft’s runtime on multiple OSes. It does not let a Figma plugin, a web CDN viewer, a Swift codebase, and an arbitrary AI agent all read and write the same file without the .NET stack. Cross-platform-within-one-ecosystem is not the same problem as tool-and-model-agnostic interchange, which is the one .gui targets.
Why reuse a markup shape at all, then?
Because the resemblance is the point: models are trained on enormous amounts of tag-based markup, so an AI agent writing .gui is closer to writing JSX than to learning a novel schema (RFC-0001). Borrowing the familiar shape of XAML-family markup while dropping the runtime binding is a deliberate trade, not an accident: the goal was the most learnable possible surface for both humans and models, not a new aesthetic.
The XKCD worry only really applies to a 15th runtime. A portable interchange layer whose whole job is to convert into the existing runtimes is the opposite move: fewer re-authoring steps between the standards that already exist, not one more island beside them.
Frequently asked
Isn’t .gui just XAML with different tags?
They share a declarative, tag-based shape but not a purpose. XAML is a UI language bound to Microsoft’s runtime: it needs the .NET layout and binding engine to mean anything. .gui has no runtime of its own; it’s a portable interchange file that gets converted into XAML, SwiftUI, Compose, or HTML. You wouldn’t pick one over the other; you’d design in .gui and generate the XAML.
MAUI already runs XAML cross-platform, doesn’t that cover this?
It covers cross-platform within Microsoft’s runtime. It doesn’t let a design tool, a web viewer, a Swift codebase, and an arbitrary AI agent all read and write the same file without the .NET stack. .gui targets tool- and model-agnostic interchange, which is a different problem from one framework running on several operating systems.
Isn’t this the "15 competing standards" problem?
That reflex applies to a new runtime competing with existing ones. .gui isn’t a runtime; it’s a layer above them whose job is to convert into XAML, SwiftUI, Compose, and HTML. It aims to reduce re-authoring between existing standards, not to become a 15th framework beside them.
Why copy XAML-style markup instead of inventing a cleaner syntax?
Because familiarity is the feature. AI models are trained on huge amounts of tag-based markup, so writing .gui is close to writing JSX rather than learning a new schema. The format reuses the learnable shape of markup while dropping the runtime binding that ties XAML to .NET.