---
title: "Comparison"
description: "How GistUI Protocol v1 compares with OpenUI Lang, Google A2UI, Vercel json-render, MCP Apps and AG-UI - what each one is, measured differences, and when to use which."
---

> Documentation Index
> Fetch the complete documentation index at: https://gistui.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Comparison

These projects are often mentioned together, but they solve different parts of the problem. Some are formats, some are transports, and several work with GistUI rather than against it.

## What each one is

| | Kind | The model writes | Maintained by |
|---|---|---|---|
| **GistUI Format** | Content format + reference library | Line-based text, catalog-directed | GistUI (open source, MIT) |
| **OpenUI Lang** | Content format + library | Line-based text | Thesys |
| **A2UI** | Message protocol for agent-driven UI | JSON messages: a flat component list and a data model | Google |
| **json-render** | Library with a JSON UI spec | A JSON tree constrained by a catalog | Vercel |
| **MCP Apps** | Extension to MCP | Nothing: the server ships an HTML view shown in a sandboxed iframe | MCP |
| **AG-UI** | Event protocol between agents and frontends | Nothing specific: it carries text, tool calls and state | AG-UI |

AG-UI and MCP are **transports**. GistUI programs travel inside them: see [Bindings](/docs/protocol/bindings/).

## Feature by feature

| | GistUI Format | OpenUI Lang | A2UI | json-render |
|---|---|---|---|---|
| Syntax | Text, one statement per line | Text, one statement per line | JSON | JSON |
| Usable before the answer ends | Yes, per line | Yes, per line | Per message | Needs a partial-JSON parser |
| Data | Pipe tables, shared between components | Arrays in arguments | A data model, bound by path | Inline in props |
| Optional props | Named, in any order | Positional | Named keys | Named keys |
| Client-side state and expressions | Yes | Yes | Data model updates from the agent; client functions | Limited |
| Read tools vs write tools | Separate in the format | One kind | Agent-side | App-defined |
| Defined recovery from syntax slips | Yes, numbered rules | Not specified | Not applicable: invalid JSON fails | Not applicable |
| Deterministic repair of a finished answer | Yes, in code | Paid add-on | No | No |
| Edits by id | Replace, patch, append, delete | Replace | `updateComponents`, `updateDataModel` | Patches |
| Written specification | Yes, with conformance classes | Documentation | Yes | Documentation |
| Public conformance suite | 149 cases | No | Schema validation | No |
| Resource limits in the format | Yes | No | No | No |
| Reference renderers | React, Vue, Svelte, Solid, vanilla JS | React | Lit, Angular, Flutter, others | React, others |

> **Checked on 2026-10-02**
>
> Other projects move quickly. This table reflects their public documentation on that date (A2UI 0.9.1, json-render 0.19, OpenUI lang-core 0.2.16). If something here is out of date, please [open an issue](https://github.com/GistUI/GistUI/issues).

## Measured

Measured against OpenUI Lang. Full results and the method: [Benchmarks](/docs/reference/benchmarks/).

| | OpenUI Lang | GistUI Format |
|---|---:|---:|
| Main-thread time to render a streaming dashboard in Chrome | 2,204 ms | **492 ms** |
| Valid answers as written (gpt-oss-120b, 182 answers) | 84.6% | **87.9%** |
| Valid after repair | a second model call in OpenUI Cloud, not measured | **100%**, in code, no model call |
| System prompt, same 70-component catalog | 5,017 tokens | **3,874 tokens** |
| Answer, mean | 601 tokens | **587 tokens** |
| First-load JavaScript, default components, gzip | 699 KB | **74 KB** |

- **Rendering:** 2–6× less main-thread work across OpenUI's own sample screens, in the same page at the same streaming pace. The gap grows with the length of the answer.
- **Parsing a stream:** OpenUI re-reads the whole answer on every chunk, so its cost grows with the square of the answer's length; GistUI reads each new character once.
- **Accuracy:** the model test uses OpenUI's own benchmark, [`thesysdev/generative-ui-bench`](https://github.com/thesysdev/generative-ui-bench), with the same catalog, examples and settings for both formats.

## When to use which

- **You want model answers rendered as native UI in your own app, in any framework, cheaply and safely.** GistUI.
- **You are building agents that drive UI across several client platforms, including native mobile, with the agent holding the state.** A2UI is designed for that. A GistUI tree can be compiled to A2UI messages: see [Bindings](/docs/protocol/bindings/#a2ui).
- **You need arbitrary HTML and scripts from a tool, isolated in an iframe.** MCP Apps. A GistUI renderer can be the content of such a view.
- **You need an event stream between an agent backend and a frontend.** AG-UI, with GistUI as the content of its text messages.
- **You are already invested in one of the other libraries and it works.** Stay. A format matters most when you need portability, a second implementation or a stated safety model.

## They compose

```text
agent framework ──AG-UI events──► your server ──text──► <GistUI>
MCP server ──tool result (text/vnd.gistui)──► MCP host ──► GistUI renderer
GistUI tree ──compile──► A2UI messages ──► an A2UI renderer
```

Source: https://gistui.com/docs/protocol/comparison/index.mdx