.gui is not a runtime: it’s a file you open and see

Almost every skeptical question about .gui ("so it’s XAML?", "why not just HTML?", "isn’t this another framework?") comes from one wrong assumption: that .gui is a runtime you have to set up, wire together, and execute to get anything out of. It isn’t. The single sentence that resolves most of the confusion is this: .gui is a file format, not a runtime. It’s something you open and see, the way you open an image.

Two things a runtime makes you do that .gui doesn’t

A runtime (a browser running HTML/CSS/JS, the .NET stack running XAML, Qt running QML) asks two things of you before you can see a UI. First, set it up: install the framework, its toolchain, its dependencies, a dev server. Second, execute it: the interface only exists after code runs, and it can render differently depending on timing, data, or a script that hasn’t finished (.gui vs HTML). A .gui file asks for neither. There is nothing to install and no code to run, because the file already is the interface, sitting there fully described.

It behaves like an image, not like source code

This is the part the "interchange format" framing undersells. Yes, .gui moves cleanly between tools, but it isn’t only a courier that’s meaningless until some other tool ingests it. It’s a standalone artifact, the way .png, .pdf, and .svg are. You don’t "set up" a PNG; you open it and see the picture. You don’t compile a PDF; you open it and read it. A .gui file is meant to work the same way: double-click it, and you see the interface, because the file already contains everything it needs to be shown (the design.guix markup, the assets/ folder, and a rendered preview.webp thumbnail, all in one package, per RFC-0004).

The reason it can behave like an image is precisely because it isn’t a runtime. A file that runs no logic and depends on no framework has a single, fixed appearance, so a viewer can just show it, with no execution step in between (Intent vs geometry). The reference renderer, the one-line <gui-embed> script, and any future native previewer are all just viewers for a file that already knows what it looks like, the same role a PDF reader plays for a PDF, not the role a browser plays for a web app.

Then what are the CLI, kit, and embed for?

Reasonable question, since they look like "setup." They aren’t required to view a file; they’re optional tools for producing and embedding one. The CLI validates and packages a file an agent wrote; the kit lets a third-party app read and render .gui; embed drops a viewer onto a web page with one script tag. None of them is a runtime the file depends on to exist, the way a React app depends on React. Take them all away and the file is still a complete, viewable description of an interface; it just wouldn’t have a fancy viewer wrapped around it yet.

Why this matters for where the format is going

The end state is the one every standalone file format reached: a .gui file is as easy to open as a .png. You get one from an AI agent, from a design tool export, or from a teammate, and you see it immediately; then, if you want, you edit it, version it, or convert it to code. "Interchange" is one thing it’s good for. "Stands on its own" is what makes it a format at all, rather than an intermediate representation that only exists in transit between two other tools.