From e6dc38a874e84629e55ae31151dfa57fcc7fd96c Mon Sep 17 00:00:00 2001
From: Aditya Pandey <aditya@thesys.dev>
Date: Sun, 19 Apr 2026 12:33:13 +0530
Subject: [PATCH 1/4] Add feature comparison documentation for OpenUI

---
 docs/content/docs/openui-lang/comparison.mdx | 161 +++++++++++++++++++
 docs/content/docs/openui-lang/meta.json      |   1 +
 2 files changed, 162 insertions(+)
 create mode 100644 docs/content/docs/openui-lang/comparison.mdx

diff --git a/docs/content/docs/openui-lang/comparison.mdx b/docs/content/docs/openui-lang/comparison.mdx
new file mode 100644
index 000000000..5072d5e79
--- /dev/null
+++ b/docs/content/docs/openui-lang/comparison.mdx
@@ -0,0 +1,161 @@
+---
+title: Feature Comparison
+description: How OpenUI compares to other generative UI frameworks like Vercel JSON-Render and Google A2UI.
+---
+
+Building generative UI — where an AI model creates interactive interfaces on the fly — is a new category. Several frameworks have emerged, each with different philosophies. This page compares OpenUI against two prominent alternatives so you can understand the landscape and make an informed choice.
+
+## At a Glance
+
+| Capability | OpenUI | JSON-Render (Vercel) | A2UI (Google) |
+| --- | --- | --- | --- |
+| **What the LLM generates** | Compact DSL (OpenUI Lang) | JSON Patch stream (RFC 6902) | JSON blocks in `<a2ui-json>` tags |
+| **Token efficiency** | Up to **67% fewer tokens** than JSON | Baseline JSON | Baseline JSON |
+| **Streaming** | Line-by-line, progressive render | JSONL patches, progressive render | JSONL, progressive render |
+| **Component guardrails** | Component library with Zod schemas | Catalog with Zod schemas | Catalog with JSON Schema |
+| **Prompt generation** | Automatic from library | Automatic from catalog | Automatic from catalog |
+| **State management** | `$variables` — language-native | JSON Pointer paths + store | JSON Pointer paths + signals |
+| **Data fetching** | `Query()` / `Mutation()` built into language | External (via actions) | External (via agent events) |
+| **Reactive bindings** | `$binding` props, auto re-fetch | `$bindState`, `$state` expressions | `DynamicString`, two-way binding |
+| **Form validation** | Built-in validators | Built-in validators | Built-in checks |
+| **Prebuilt components** | 40+ (charts, tables, forms, layouts) | 36 (shadcn/Radix) | ~25 (basic catalog) |
+| **Chart components** | 6 types (bar, line, area, pie, radar, scatter) | Via custom catalog | Not built-in |
+| **Chat layouts** | 3 ready-to-use (Fullscreen, Copilot, BottomTray) | Custom | Not included |
+| **Web frameworks** | React, Vue, Svelte | React, Vue, Svelte, Solid | React, Angular, Lit |
+| **Mobile** | React Native | React Native, Flutter (via 3rd party) | Flutter, SwiftUI (planned) |
+| **MCP support** | Native — pass MCP client directly | Via integration package | Transport-agnostic |
+| **CLI scaffolding** | `npx @openuidev/cli create` | Manual setup | Manual setup |
+| **License** | MIT | MIT | Apache 2.0 |
+
+## The Core Difference: Language vs JSON
+
+The most important distinction is **what the model actually generates**.
+
+JSON-Render and A2UI both ask the LLM to produce JSON — a format designed for machines, not for streaming generation. JSON requires balanced braces, quoted keys, and rigid nesting. When an LLM is mid-generation, a partially produced JSON object is invalid and unparseable.
+
+OpenUI takes a different approach. The LLM writes in **OpenUI Lang**, a line-oriented DSL where each line is independently valid:
+
+```text
+root = Card([header, chart, controls])
+header = CardHeader("Sales Dashboard")
+chart = BarChart(data.columns, data.results)
+data = Query("getSales", {region: $region}, {columns: [], results: []})
+$region = "US"
+controls = Select($region, ["US", "EU", "APAC"])
+```
+
+Each line parses and renders as soon as it arrives. No waiting for a closing brace. No buffering incomplete objects. The UI appears progressively, token by token.
+
+### Why Token Efficiency Matters
+
+Fewer tokens means:
+- **Faster responses** — the model finishes sooner
+- **Lower cost** — you pay per token
+- **More room for context** — the model can focus on your data, not on JSON syntax
+
+In [our benchmarks](/docs/benchmarks), OpenUI Lang uses **52–67% fewer tokens** than JSON-based formats across real-world UI scenarios like dashboards, forms, and data tables.
+
+## Data Fetching as a Language Primitive
+
+In JSON-Render and A2UI, fetching data requires wiring up actions, event handlers, or external integrations. The model generates UI structure, and you separately connect it to your backend.
+
+In OpenUI, data fetching is part of the language itself:
+
+```text
+users = Query("getUsers", {role: $role}, {rows: []})
+table = Table(users.columns, users.rows)
+$role = "admin"
+roleFilter = Select($role, ["admin", "editor", "viewer"])
+```
+
+This single snippet:
+1. Declares a query that fetches data via your tool provider (REST, MCP, or custom)
+2. Renders results in a table
+3. Binds a filter to `$role` — when the user changes it, the query **automatically re-fetches**
+4. Shows default empty data while loading
+
+No glue code. No event handlers. No action wiring. The model writes it, and it works.
+
+## Reactivity Without Complexity
+
+All three frameworks support reactive state, but the approaches differ significantly in what the LLM needs to generate.
+
+**JSON-Render** uses JSON Pointer expressions:
+```json
+{
+  "type": "Text",
+  "props": {
+    "content": { "$template": "Hello, {{/user/name}}!" }
+  }
+}
+```
+
+**A2UI** uses dynamic value objects:
+```json
+{
+  "type": "Text",
+  "props": {
+    "text": { "$data": "/greeting" }
+  }
+}
+```
+
+**OpenUI** uses simple `$variables`:
+```text
+greeting = TextContent("Hello, " + $name + "!")
+$name = "World"
+nameInput = Input($name, "Enter your name")
+```
+
+The `$` prefix is all the model needs to learn. No pointer syntax, no expression objects, no special wrapper types. When `$name` changes, everything that references it updates.
+
+## Built for Chat and Copilot Experiences
+
+OpenUI ships with production-ready chat layouts — not just a renderer:
+
+- **FullScreen** — full-page chat interface
+- **Copilot** — slide-out panel for assistant experiences
+- **BottomTray** — mobile-friendly bottom sheet
+
+These include threading, message history, streaming indicators, and follow-up suggestions out of the box. JSON-Render and A2UI focus on the rendering layer and leave chat UI to you.
+
+Combined with the headless state management layer (`@openuidev/react-headless`), you get a complete chat application framework — not just a component renderer.
+
+## Component Libraries: Ready to Use
+
+OpenUI includes **40+ prebuilt components** designed for the most common generative UI scenarios:
+
+- **6 chart types** — Bar, Line, Area, Pie, Radar, Scatter — that accept query results directly
+- **Data tables** with sorting and column definitions
+- **Form controls** — inputs, selects, checkboxes, sliders, date pickers
+- **Layout primitives** — cards, stacks, tabs, accordions, carousels
+- **Content blocks** — markdown, code blocks, images, callouts
+
+Charts are particularly important for generative UI. When a user asks "show me last quarter's revenue", the model should be able to generate a chart immediately. In OpenUI:
+
+```text
+chart = BarChart(revenue.columns, revenue.results)
+revenue = Query("getRevenue", {quarter: "Q4"}, {columns: [], results: []})
+```
+
+JSON-Render and A2UI don't include chart components — you'd need to build and register them yourself.
+
+## Getting Started in One Command
+
+```bash
+npx @openuidev/cli@latest create --name my-app
+```
+
+This scaffolds a complete Next.js application with streaming, prebuilt UI, and OpenUI Lang support. You get a working chat interface in under a minute.
+
+JSON-Render and A2UI require manual project setup, dependency configuration, and boilerplate wiring.
+
+## When to Use What
+
+**Choose OpenUI** if you want the fastest path to a production generative UI — with streaming chat, built-in data fetching, charts, and token-efficient generation out of the box.
+
+**Choose JSON-Render** if you need to render the same UI spec across many platforms (web, mobile, email, PDF, video, 3D) from a single JSON definition, and you're willing to trade token efficiency for format universality.
+
+**Choose A2UI** if you're building in a multi-agent ecosystem (A2A protocol) where agents communicate UI across trust boundaries, and you need the strictest security guarantees around declarative-only output.
+
+All three frameworks share the same core insight: LLMs should generate structured UI, not raw HTML. OpenUI optimizes for the developer building a generative AI product today — fewer tokens, less boilerplate, more built-in functionality.
diff --git a/docs/content/docs/openui-lang/meta.json b/docs/content/docs/openui-lang/meta.json
index a8e048ed4..25de05647 100644
--- a/docs/content/docs/openui-lang/meta.json
+++ b/docs/content/docs/openui-lang/meta.json
@@ -3,6 +3,7 @@
   "root": true,
   "pages": [
     "index",
+    "comparison",
     "quickstart",
     "---Core Concepts---",
     "overview",

From 772ff579f977ea247b8a95d95ee05a0110a63054 Mon Sep 17 00:00:00 2001
From: Aditya Pandey <aditya@thesys.dev>
Date: Thu, 23 Apr 2026 20:01:22 +0530
Subject: [PATCH 2/4] update comparison

---
 docs/content/docs/openui-lang/comparison.mdx | 176 ++++++-------------
 1 file changed, 50 insertions(+), 126 deletions(-)

diff --git a/docs/content/docs/openui-lang/comparison.mdx b/docs/content/docs/openui-lang/comparison.mdx
index 5072d5e79..0ce780996 100644
--- a/docs/content/docs/openui-lang/comparison.mdx
+++ b/docs/content/docs/openui-lang/comparison.mdx
@@ -1,161 +1,85 @@
 ---
 title: Feature Comparison
-description: How OpenUI compares to other generative UI frameworks like Vercel JSON-Render and Google A2UI.
+description: OpenUI vs json-render (Vercel), A2UI (Google), and CopilotKit OpenGenerativeUI.
 ---
 
-Building generative UI — where an AI model creates interactive interfaces on the fly — is a new category. Several frameworks have emerged, each with different philosophies. This page compares OpenUI against two prominent alternatives so you can understand the landscape and make an informed choice.
+# The Generative UI Landscape
 
-## At a Glance
-
-| Capability | OpenUI | JSON-Render (Vercel) | A2UI (Google) |
-| --- | --- | --- | --- |
-| **What the LLM generates** | Compact DSL (OpenUI Lang) | JSON Patch stream (RFC 6902) | JSON blocks in `<a2ui-json>` tags |
-| **Token efficiency** | Up to **67% fewer tokens** than JSON | Baseline JSON | Baseline JSON |
-| **Streaming** | Line-by-line, progressive render | JSONL patches, progressive render | JSONL, progressive render |
-| **Component guardrails** | Component library with Zod schemas | Catalog with Zod schemas | Catalog with JSON Schema |
-| **Prompt generation** | Automatic from library | Automatic from catalog | Automatic from catalog |
-| **State management** | `$variables` — language-native | JSON Pointer paths + store | JSON Pointer paths + signals |
-| **Data fetching** | `Query()` / `Mutation()` built into language | External (via actions) | External (via agent events) |
-| **Reactive bindings** | `$binding` props, auto re-fetch | `$bindState`, `$state` expressions | `DynamicString`, two-way binding |
-| **Form validation** | Built-in validators | Built-in validators | Built-in checks |
-| **Prebuilt components** | 40+ (charts, tables, forms, layouts) | 36 (shadcn/Radix) | ~25 (basic catalog) |
-| **Chart components** | 6 types (bar, line, area, pie, radar, scatter) | Via custom catalog | Not built-in |
-| **Chat layouts** | 3 ready-to-use (Fullscreen, Copilot, BottomTray) | Custom | Not included |
-| **Web frameworks** | React, Vue, Svelte | React, Vue, Svelte, Solid | React, Angular, Lit |
-| **Mobile** | React Native | React Native, Flutter (via 3rd party) | Flutter, SwiftUI (planned) |
-| **MCP support** | Native — pass MCP client directly | Via integration package | Transport-agnostic |
-| **CLI scaffolding** | `npx @openuidev/cli create` | Manual setup | Manual setup |
-| **License** | MIT | MIT | Apache 2.0 |
-
-## The Core Difference: Language vs JSON
-
-The most important distinction is **what the model actually generates**.
-
-JSON-Render and A2UI both ask the LLM to produce JSON — a format designed for machines, not for streaming generation. JSON requires balanced braces, quoted keys, and rigid nesting. When an LLM is mid-generation, a partially produced JSON object is invalid and unparseable.
-
-OpenUI takes a different approach. The LLM writes in **OpenUI Lang**, a line-oriented DSL where each line is independently valid:
+**Four frameworks. One question: how should AI talk to your UI?**
 
-```text
-root = Card([header, chart, controls])
-header = CardHeader("Sales Dashboard")
-chart = BarChart(data.columns, data.results)
-data = Query("getSales", {region: $region}, {columns: [], results: []})
-$region = "US"
-controls = Select($region, ["US", "EU", "APAC"])
-```
-
-Each line parses and renders as soon as it arrives. No waiting for a closing brace. No buffering incomplete objects. The UI appears progressively, token by token.
+---
 
-### Why Token Efficiency Matters
+## At a Glance
 
-Fewer tokens means:
-- **Faster responses** — the model finishes sooner
-- **Lower cost** — you pay per token
-- **More room for context** — the model can focus on your data, not on JSON syntax
+|  | **[OpenUI](https://github.com/thesysdev/openui)** | **[json-render](https://github.com/vercel-labs/json-render)** (Vercel) | **[A2UI](https://github.com/google/A2UI)** (Google) | **[CopilotKit OpenGenUI](https://github.com/CopilotKit/OpenGenerativeUI)** |
+|---|---|---|---|---|
+| **Token efficiency** | **Up to 67% fewer than JSON** | Baseline | Similar to JSON | Higher (raw HTML boilerplate) |
+| **Format** | OpenUI Lang (DSL) | JSON (RFC 6902 patches) | Declarative JSON | Raw HTML/SVG |
+| **Streaming** | Line-by-line | JSONL patches | Incremental updates | Sandboxed iframe |
+| **Data fetching** | `Query()` / `Mutation()`, MCP-native in the language | App-level (via `@json-render/mcp`) | Agent roundtrip | Skills + agent tools |
+| **Reactive state** | `$vars` + two-way binding | `$state` / `$computed` | Data model + JSON Pointer | CopilotKit shared state |
+| **Design system adherence** | Enforced via library + Zod | Enforced via catalog + Zod | Enforced via catalog | None; every output is a one-off |
+| **Components** | Out of box (charts, forms, tables, modals, chat shells) + your own library | Out of box (36 shadcn/ui) + your own library | Bring your own | None; agent generates HTML/SVG |
+| **Framework adapters** | React, Vue, Svelte | React, Vue, Svelte, Solid, RN, PDF, email, video, terminal, 3D | Angular, Flutter, Lit, React | React (Next.js) |
+| **Chat UI** | FullScreen, Copilot, BottomTray | Build your own | Build your own | CopilotKit chat |
+| **Agent integrations** | AI SDK, LangGraph, AG-UI, OpenAI | AI SDK | A2A, AG UI | LangGraph, CopilotKit v2 |
+| **License** | MIT | Apache 2.0 | Apache 2.0 | MIT |
 
-In [our benchmarks](/docs/benchmarks), OpenUI Lang uses **52–67% fewer tokens** than JSON-based formats across real-world UI scenarios like dashboards, forms, and data tables.
+---
 
-## Data Fetching as a Language Primitive
+## The Key Differences
 
-In JSON-Render and A2UI, fetching data requires wiring up actions, event handlers, or external integrations. The model generates UI structure, and you separately connect it to your backend.
+### What the LLM writes
 
-In OpenUI, data fetching is part of the language itself:
+OpenUI Lang is a DSL where every line is independently valid, so UIs stream token-by-token with no broken intermediate states. json-render and A2UI use JSON (patch-based and tree-based) that needs balanced braces before a client can parse cleanly. CopilotKit streams raw HTML/SVG, which flickers as partial tags arrive.
 
 ```text
-users = Query("getUsers", {role: $role}, {rows: []})
-table = Table(users.columns, users.rows)
-$role = "admin"
-roleFilter = Select($role, ["admin", "editor", "viewer"])
+root   = Card([header, chart])
+header = CardHeader("Sales")
+chart  = BarChart(data.columns, data.results)
+data   = Query("getSales", {}, {columns: [], results: []})
 ```
 
-This single snippet:
-1. Declares a query that fetches data via your tool provider (REST, MCP, or custom)
-2. Renders results in a table
-3. Binds a filter to `$role` — when the user changes it, the query **automatically re-fetches**
-4. Shows default empty data while loading
+Each line renders the moment it arrives. No buffering, no waiting on a closing brace.
 
-No glue code. No event handlers. No action wiring. The model writes it, and it works.
+### Code generation vs intent
 
-## Reactivity Without Complexity
+CopilotKit OpenGenerativeUI has the LLM generate raw HTML/SVG into a sandboxed iframe. **Shines for:** creative one-offs (algorithm animations, diagrams, generative art), zero learning curve, fastest demo path. **Breaks down as a product:** no shared design system across outputs, heavy token cost per UI, iframe-based multi-surface is awkward, and partial HTML streams as flickering broken renders.
 
-All three frameworks support reactive state, but the approaches differ significantly in what the LLM needs to generate.
+OpenUI, json-render, and A2UI take the opposite stance: **the model describes intent, the renderer owns the pixels.**
 
-**JSON-Render** uses JSON Pointer expressions:
-```json
-{
-  "type": "Text",
-  "props": {
-    "content": { "$template": "Hello, {{/user/name}}!" }
-  }
-}
-```
+### Data fetching
 
-**A2UI** uses dynamic value objects:
-```json
-{
-  "type": "Text",
-  "props": {
-    "text": { "$data": "/greeting" }
-  }
-}
-```
+OpenUI is the only one where the generated UI fetches data directly. No LLM roundtrip per change:
 
-**OpenUI** uses simple `$variables`:
 ```text
-greeting = TextContent("Hello, " + $name + "!")
-$name = "World"
-nameInput = Input($name, "Enter your name")
+$days  = "7"
+filter = Select("days", $days, [SelectItem("7", "7 days"), SelectItem("30", "30 days")])
+data   = Query("get_analytics", {days: $days}, {rows: []})
+chart  = LineChart(data.rows.day, [Series("Revenue", data.rows.revenue)])
 ```
 
-The `$` prefix is all the model needs to learn. No pointer syntax, no expression objects, no special wrapper types. When `$name` changes, everything that references it updates.
-
-## Built for Chat and Copilot Experiences
-
-OpenUI ships with production-ready chat layouts — not just a renderer:
-
-- **FullScreen** — full-page chat interface
-- **Copilot** — slide-out panel for assistant experiences
-- **BottomTray** — mobile-friendly bottom sheet
+Dropdown changes → query re-fetches → chart updates. The LLM generates UI once and gets out of the way.
 
-These include threading, message history, streaming indicators, and follow-up suggestions out of the box. JSON-Render and A2UI focus on the rendering layer and leave chat UI to you.
+json-render leaves fetching to app code. A2UI routes every data change through the agent. CopilotKit drives updates via agent tool calls.
 
-Combined with the headless state management layer (`@openuidev/react-headless`), you get a complete chat application framework — not just a component renderer.
+### Platform coverage
 
-## Component Libraries: Ready to Use
+json-render's standout: one catalog renders to web, mobile, PDF, email, video (Remotion), terminal (Ink), and 3D (R3F). Built for teams that need the same UI spec across surfaces.
 
-OpenUI includes **40+ prebuilt components** designed for the most common generative UI scenarios:
+### Cross-platform reach
 
-- **6 chart types** — Bar, Line, Area, Pie, Radar, Scatter — that accept query results directly
-- **Data tables** with sorting and column definitions
-- **Form controls** — inputs, selects, checkboxes, sliders, date pickers
-- **Layout primitives** — cards, stacks, tabs, accordions, carousels
-- **Content blocks** — markdown, code blocks, images, callouts
+A2UI ships native renderers for Angular, Flutter, Lit, and React by keeping the format purely declarative, so every client's runtime is trivial. OpenUI and json-render make the opposite trade: richer format, more runtime per platform. Porting `lang-core` to Swift or Dart is engineering work, not an architectural blocker.
 
-Charts are particularly important for generative UI. When a user asks "show me last quarter's revenue", the model should be able to generate a chart immediately. In OpenUI:
+What A2UI genuinely adds is the **A2A transport**: a standard envelope for agents to hand rendered UI to each other across trust boundaries.
 
-```text
-chart = BarChart(revenue.columns, revenue.results)
-revenue = Query("getRevenue", {quarter: "Q4"}, {columns: [], results: []})
-```
-
-JSON-Render and A2UI don't include chart components — you'd need to build and register them yourself.
-
-## Getting Started in One Command
-
-```bash
-npx @openuidev/cli@latest create --name my-app
-```
-
-This scaffolds a complete Next.js application with streaming, prebuilt UI, and OpenUI Lang support. You get a working chat interface in under a minute.
-
-JSON-Render and A2UI require manual project setup, dependency configuration, and boilerplate wiring.
+---
 
 ## When to Use What
 
-**Choose OpenUI** if you want the fastest path to a production generative UI — with streaming chat, built-in data fetching, charts, and token-efficient generation out of the box.
-
-**Choose JSON-Render** if you need to render the same UI spec across many platforms (web, mobile, email, PDF, video, 3D) from a single JSON definition, and you're willing to trade token efficiency for format universality.
-
-**Choose A2UI** if you're building in a multi-agent ecosystem (A2A protocol) where agents communicate UI across trust boundaries, and you need the strictest security guarantees around declarative-only output.
-
-All three frameworks share the same core insight: LLMs should generate structured UI, not raw HTML. OpenUI optimizes for the developer building a generative AI product today — fewer tokens, less boilerplate, more built-in functionality.
+| Use case | Best fit |
+|---|---|
+| Data-driven chat UIs, dashboards, CRUD with live data | **OpenUI** |
+| Multi-target rendering (web + PDF + email + video + 3D) | **json-render** |
+| Cross-platform native, multi-agent across trust boundaries | **A2UI** |
+| Creative visual output: algorithm animations, generative art | **CopilotKit OpenGenUI** |

From 016b80d7f2fd31c055023b4e6bee067e850e8d96 Mon Sep 17 00:00:00 2001
From: Aditya Pandey <aditya@thesys.dev>
Date: Thu, 23 Apr 2026 21:17:04 +0530
Subject: [PATCH 3/4] update comparison

---
 docs/content/docs/openui-lang/comparison.mdx | 82 ++++----------------
 1 file changed, 16 insertions(+), 66 deletions(-)

diff --git a/docs/content/docs/openui-lang/comparison.mdx b/docs/content/docs/openui-lang/comparison.mdx
index 0ce780996..c24ef98c8 100644
--- a/docs/content/docs/openui-lang/comparison.mdx
+++ b/docs/content/docs/openui-lang/comparison.mdx
@@ -5,7 +5,7 @@ description: OpenUI vs json-render (Vercel), A2UI (Google), and CopilotKit OpenG
 
 # The Generative UI Landscape
 
-**Four frameworks. One question: how should AI talk to your UI?**
+**Four frameworks. Which one ships to production?**
 
 ---
 
@@ -13,73 +13,23 @@ description: OpenUI vs json-render (Vercel), A2UI (Google), and CopilotKit OpenG
 
 |  | **[OpenUI](https://github.com/thesysdev/openui)** | **[json-render](https://github.com/vercel-labs/json-render)** (Vercel) | **[A2UI](https://github.com/google/A2UI)** (Google) | **[CopilotKit OpenGenUI](https://github.com/CopilotKit/OpenGenerativeUI)** |
 |---|---|---|---|---|
-| **Token efficiency** | **Up to 67% fewer than JSON** | Baseline | Similar to JSON | Higher (raw HTML boilerplate) |
-| **Format** | OpenUI Lang (DSL) | JSON (RFC 6902 patches) | Declarative JSON | Raw HTML/SVG |
-| **Streaming** | Line-by-line | JSONL patches | Incremental updates | Sandboxed iframe |
-| **Data fetching** | `Query()` / `Mutation()`, MCP-native in the language | App-level (via `@json-render/mcp`) | Agent roundtrip | Skills + agent tools |
-| **Reactive state** | `$vars` + two-way binding | `$state` / `$computed` | Data model + JSON Pointer | CopilotKit shared state |
-| **Design system adherence** | Enforced via library + Zod | Enforced via catalog + Zod | Enforced via catalog | None; every output is a one-off |
-| **Components** | Out of box (charts, forms, tables, modals, chat shells) + your own library | Out of box (36 shadcn/ui) + your own library | Bring your own | None; agent generates HTML/SVG |
-| **Framework adapters** | React, Vue, Svelte | React, Vue, Svelte, Solid, RN, PDF, email, video, terminal, 3D | Angular, Flutter, Lit, React | React (Next.js) |
-| **Chat UI** | FullScreen, Copilot, BottomTray | Build your own | Build your own | CopilotKit chat |
-| **Agent integrations** | AI SDK, LangGraph, AG-UI, OpenAI | AI SDK | A2A, AG UI | LangGraph, CopilotKit v2 |
+| **Tokens** | **1x** | 3x | 3x | 4x |
+| **Latency (60 tok/s)** | **4.9s** | 14.2s | 14.2s | ~20s |
+| **Streaming** | Yes | Yes | Yes | Partial |
+| **Consistent output** | Yes | Yes | Yes | No |
+| **Design system** | Yes | Yes | Yes | No |
+| **Components** | Library + custom | Library + custom | Custom only | None |
+| **Built-in data fetching** | Yes | No | No | No |
+| **Chat UI included** | Yes | No | No | Yes |
+| **Multi-platform** | Web, mobile, email | Web, mobile, PDF, email, video | Web, iOS, Android | Web |
+| **Security risk** | Minimal | Minimal | Minimal | Medium |
 | **License** | MIT | Apache 2.0 | Apache 2.0 | MIT |
 
 ---
 
-## The Key Differences
+## Best For
 
-### What the LLM writes
-
-OpenUI Lang is a DSL where every line is independently valid, so UIs stream token-by-token with no broken intermediate states. json-render and A2UI use JSON (patch-based and tree-based) that needs balanced braces before a client can parse cleanly. CopilotKit streams raw HTML/SVG, which flickers as partial tags arrive.
-
-```text
-root   = Card([header, chart])
-header = CardHeader("Sales")
-chart  = BarChart(data.columns, data.results)
-data   = Query("getSales", {}, {columns: [], results: []})
-```
-
-Each line renders the moment it arrives. No buffering, no waiting on a closing brace.
-
-### Code generation vs intent
-
-CopilotKit OpenGenerativeUI has the LLM generate raw HTML/SVG into a sandboxed iframe. **Shines for:** creative one-offs (algorithm animations, diagrams, generative art), zero learning curve, fastest demo path. **Breaks down as a product:** no shared design system across outputs, heavy token cost per UI, iframe-based multi-surface is awkward, and partial HTML streams as flickering broken renders.
-
-OpenUI, json-render, and A2UI take the opposite stance: **the model describes intent, the renderer owns the pixels.**
-
-### Data fetching
-
-OpenUI is the only one where the generated UI fetches data directly. No LLM roundtrip per change:
-
-```text
-$days  = "7"
-filter = Select("days", $days, [SelectItem("7", "7 days"), SelectItem("30", "30 days")])
-data   = Query("get_analytics", {days: $days}, {rows: []})
-chart  = LineChart(data.rows.day, [Series("Revenue", data.rows.revenue)])
-```
-
-Dropdown changes → query re-fetches → chart updates. The LLM generates UI once and gets out of the way.
-
-json-render leaves fetching to app code. A2UI routes every data change through the agent. CopilotKit drives updates via agent tool calls.
-
-### Platform coverage
-
-json-render's standout: one catalog renders to web, mobile, PDF, email, video (Remotion), terminal (Ink), and 3D (R3F). Built for teams that need the same UI spec across surfaces.
-
-### Cross-platform reach
-
-A2UI ships native renderers for Angular, Flutter, Lit, and React by keeping the format purely declarative, so every client's runtime is trivial. OpenUI and json-render make the opposite trade: richer format, more runtime per platform. Porting `lang-core` to Swift or Dart is engineering work, not an architectural blocker.
-
-What A2UI genuinely adds is the **A2A transport**: a standard envelope for agents to hand rendered UI to each other across trust boundaries.
-
----
-
-## When to Use What
-
-| Use case | Best fit |
-|---|---|
-| Data-driven chat UIs, dashboards, CRUD with live data | **OpenUI** |
-| Multi-target rendering (web + PDF + email + video + 3D) | **json-render** |
-| Cross-platform native, multi-agent across trust boundaries | **A2UI** |
-| Creative visual output: algorithm animations, generative art | **CopilotKit OpenGenUI** |
+- **Data-driven chat UIs and dashboards** → OpenUI
+- **One UI across web, mobile, PDF, email, and video** → json-render
+- **Multi-agent systems across iOS, Android, and web** → A2UI
+- **Creative one-off visuals (animations, generative art)** → CopilotKit OpenGenUI

From edb25a88491a87f37d4ddb328746ea2e50878d51 Mon Sep 17 00:00:00 2001
From: Aditya Pandey <aditya@thesys.dev>
Date: Mon, 4 May 2026 12:02:39 +0530
Subject: [PATCH 4/4] Update feature comparison for OpenUI

---
 docs/content/docs/openui-lang/comparison.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/content/docs/openui-lang/comparison.mdx b/docs/content/docs/openui-lang/comparison.mdx
index c24ef98c8..c948b4fdf 100644
--- a/docs/content/docs/openui-lang/comparison.mdx
+++ b/docs/content/docs/openui-lang/comparison.mdx
@@ -30,6 +30,6 @@ description: OpenUI vs json-render (Vercel), A2UI (Google), and CopilotKit OpenG
 ## Best For
 
 - **Data-driven chat UIs and dashboards** → OpenUI
-- **One UI across web, mobile, PDF, email, and video** → json-render
-- **Multi-agent systems across iOS, Android, and web** → A2UI
+- **One UI across web, mobile, PDF and email** → OpenUI
+- **Multi-agent systems across iOS, Android, and web** → OpenUI
 - **Creative one-off visuals (animations, generative art)** → CopilotKit OpenGenUI