OpenUI: eine eigene Sprache für modellgenerierte Interfaces

Welches Problem OpenUI adressiert

Ein Sprachmodell, das eine Oberfläche erzeugen soll, gibt üblicherweise JSON zurück. Das funktioniert, ist aber teuer: Jede geschweifte Klammer, jeder Schlüsselname und jedes Anführungszeichen wandert durch den Tokenizer, bevor der Client überhaupt etwas rendern kann. OpenUI setzt an dieser Stelle an und ersetzt das Datenformat durch OpenUI Lang, eine kompakte, auf Streaming ausgelegte Sprache. Laut README verbraucht sie bis zu 67 Prozent weniger Tokens als JSON. Wer die Zahl nachprüfen will, muss die Angabe aus dem Repository übernehmen; eine unabhängige Messung liegt hier nicht vor.

Die Zielgruppe ist enger, als der Slogan vermuten lässt. OpenUI richtet sich an Entwicklerinnen und Entwickler, die eine Chat-, Copilot- oder Assistenzoberfläche bauen und dabei festlegen wollen, welche Komponenten das Modell überhaupt erzeugen darf. Die Komponentenbibliothek ist nicht Beiwerk, sondern der Ausgangspunkt: Aus ihr wird der System-Prompt generiert. Wer nur Fließtext aus einem Modell anzeigen will, braucht dieses Framework nicht.

Vom Komponentenverzeichnis zum Live-Interface

Die Architektur ist als Kette dokumentiert. Am Anfang steht die Component Library, also die Menge der erlaubten Komponenten. Daraus wird ein System Prompt erzeugt. Dieser Prompt geht an das LLM. Das Modell antwortet mit einem OpenUI Lang Stream. Ein Renderer liest diesen Stream und erzeugt daraus die Live UI. Fünf Schritte, die das README in genau dieser Reihenfolge auflistet.

Der interessante Teil ist die Umkehrung der Kontrolle. Nicht das Modell entscheidet, welche Bausteine existieren, sondern die Komponentenbibliothek legt den Rahmen fest, und die Prompt-Generierung übersetzt diesen Rahmen in Anweisungen für das Modell. Das begrenzt, was zurückkommen kann, und macht die Ausgabe prüfbarer als freies JSON. Der Parser sitzt in @openuidev/lang-core, das laut Pakettabelle den Core Parser, die Prompt-Generierung, die Laufzeitauswertung und die Typenebene enthält, ohne Abhängigkeit von React, Vue oder Svelte. Die Framework-Bindings liegen in getrennten Paketen.

Bemerkenswert ist die Reihenfolge der Verarbeitung: geparst und gerendert wird progressiv, während die Tokens eintreffen. Das ist der Grund für die Streaming-Orientierung der Sprache. Ein JSON-Objekt lässt sich erst auswerten, wenn es vollständig ist. Eine auf Streaming ausgelegte Syntax kann dagegen schon während der Generierung Teilbäume liefern. Ob das in der Praxis flüssig aussieht, hängt vom jeweiligen Modell und der Netzwerklatenz ab; das README belegt das nicht.

Installation über den CLI-Scaffold

Der schnellste Weg führt über den CLI-Befehl aus dem Quick Start. Drei Zeilen, dann läuft die Beispielanwendung:

npx @openuidev/cli@latest create --name genui-chat-app cd genui-chat-app echo "OPENAI_API_KEY=sk-your-key-here" > .env npm run dev

Der Scaffold erzeugt laut README eine Ende-zu-Ende-Anwendung mit Streaming, eingebauter UI und Unterstützung für OpenUI Lang. Der API-Schlüssel liegt danach als OPENAI_API_KEY in einer .env-Datei im Projektverzeichnis. Wer den Schlüssel dort ablegt, sollte sicherstellen, dass .env nicht in die Versionskontrolle gerät; das README erwähnt dazu nichts.

Für den manuellen Aufbau ist die Paketliste die eigentliche Landkarte. @openuidev/react-lang definiert Komponentenbibliotheken, generiert Prompts und rendert gestreamtes OpenUI Lang in React. @openuidev/react-headless liefert den Chat-Zustand, Streaming-Adapter und Konverter für das Nachrichtenformat, ohne fertige Oberfläche. @openuidev/react-ui bringt fertige Chat-Layouts und zwei eingebaute Komponentenbibliotheken mit. Für andere Frameworks gibt es @openuidev/vue-lang und @openuidev/svelte-lang. Wer eine Agentenkette betreibt, greift zu @openuidev/langchain mit dem Agent Transformer und Server-Helfern, die OpenUI über AG-UI streamen. Und @openuidev/react-email zielt auf generierte E-Mails samt HTML-Export.

Wo das Modell die Oberfläche nicht erreicht

Die Prompt-Generierung ist die kritische Stelle im Datenfluss, und sie ist zugleich die größte Einschränkung. Alles, was das Modell erzeugen kann, muss vorher als Komponente definiert und über die Bibliothek in den Prompt übersetzt worden sein. Eine Komponente, die nicht in der Bibliothek steht, taucht im Prompt nicht auf und wird folglich auch nicht generiert. Das ist gewollt, verlangt aber Disziplin bei der Pflege der Bibliothek. Ändert sich das Designsystem, muss die Bibliothek nachgezogen werden, sonst driftet die Modellausgabe vom Produkt weg.

Zweitens ist OpenUI kein Werkzeug für reine Textantworten. Wer Zusammenfassungen, Erklärungen oder Codeblöcke ausgeben will, bezahlt den Aufwand für Parser, Prompt-Generierung und Renderer, ohne einen Gegenwert zu erhalten. Dasselbe gilt für Anwendungen, die keine Streaming-Pipeline betreiben können oder wollen: Der Vorteil der progressiven Ausgabe verpufft, wenn die Antwort ohnehin erst am Ende angezeigt wird.

Drittens bleibt die Frage der Zuverlässigkeit offen. Ein Modell, das eine formale Sprache erzeugen soll, kann diese Sprache falsch erzeugen. Das README beschreibt weder einen Validierungsschritt noch einen Fallback für fehlerhafte Ausgabe. Wer OpenUI produktiv einsetzt, muss diesen Fallback selbst bauen, und das ist Aufwand, der in der Projektbeschreibung nicht auftaucht.

Was OpenUI von JSON-Schemas unterscheidet

Der naheliegende Vergleich ist ein Ansatz, bei dem das Modell JSON gegen ein vorgegebenes Schema erzeugt und der Client dieses JSON in Komponenten übersetzt. Der Unterschied liegt nicht im Ergebnis, sondern im Weg dorthin. Beim JSON-Schema ist das Schema die Schnittstelle, und die Übersetzung von JSON in Komponenten ist ein separater Schritt, den der Client implementiert. Bei OpenUI ist die Komponentenbibliothek selbst die Quelle, aus der sowohl der Prompt als auch die Rendering-Regeln stammen. Prompt und Renderer können damit nicht auseinanderlaufen, weil sie aus derselben Definition stammen.

Der zweite Unterschied ist das Token-Budget. Das README nennt bis zu 67 Prozent weniger Tokens gegenüber JSON. Für lange Listen, Tabellen oder verschachtelte Layouts ist das der eigentliche Grund, sich das Format anzusehen. Der Preis dafür ist eine projektspezifische Syntax: Werkzeuge, die JSON verstehen, verstehen OpenUI Lang nicht. Debugging, Logging und Fehleranalyse müssen den Parser aus @openuidev/lang-core einbeziehen, ein generischer JSON-Viewer hilft nicht weiter.

Ein dritter Unterschied betrifft die Reichweite. OpenUI trennt den Kern von den Bindings, was den Einsatz außerhalb von React ermöglicht. Die Paketliste führt Vue 3 und Svelte 5 ausdrücklich als community-supported, während React als offiziell unterstützt beschrieben wird. Wer auf Vue oder Svelte setzt, sollte diesen Unterschied bei der Bewertung des Wartungsrisikos berücksichtigen.

Wartung, Lizenz und Reifegrad

Das Repository steht unter der MIT-Lizenz, wie die LICENSE-Datei und das Lizenz-Badge im README zeigen. Das ist eine permissive Lizenz: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Lizenztext und der Urheberrechtshinweis beibehalten werden. Für die meisten kommerziellen Produkte ist das unproblematisch. Eine rechtliche Bewertung ersetzt dieser Absatz nicht, und bei eingebetteten Assets oder Marken im Repository lohnt ein eigener Blick.

Zu den Release Notes liegt hier kein Material vor; die Liste der Releases wurde nicht abgerufen. Aussagen über Versionsnummern, Breaking Changes oder Upgrade-Pfade lassen sich daraus nicht ableiten. Der letzte Push auf den Hauptzweig datiert vom 9. September 2026, das Projekt ist nicht archiviert. Die Topics enthalten help-wanted und looking-for-contributors, was auf ein Projekt hindeutet, das Mitwirkende sucht. Das ist eine Beobachtung über den Zustand des Repositorys, kein Qualitätsurteil.

Für die Wartung bedeutet der Aufbau mit neun veröffentlichten Paketen, dass Aktualisierungen nicht an einer Stelle anfallen. Wer @openuidev/react-lang, @openuidev/react-headless und @openuidev/react-ui kombiniert, muss drei Versionsstände im Blick behalten. Dass keine Releases abgerufen wurden, heißt nicht, dass es keine gibt; es heißt, dass diese Prüfung hier nicht möglich war. Vor einem Upgrade empfiehlt sich deshalb ein Blick in die jeweilige Paketdokumentation statt in eine allgemeine Roadmap.

Ein Hinweis aus dem README verdient Beachtung, weil er ungewöhnlich ist: Das Projekt stellt ausdrücklich klar, dass es kein offizielles Kryptowährungs- oder Token-Asset gibt und dass jegliches Asset unter dem Namen OpenUI nicht mit den Maintainern verbunden ist. Für ein Entwicklerwerkzeug ist diese Klarstellung ein Signal, dass der Name bereits für fremde Zwecke verwendet wurde.

Redaktionelles Fazit

Sinnvoll ist OpenUI für Teams, die eine Chat- oder Copilot-Oberfläche bauen und die vom Modell erzeugte Struktur selbst kontrollieren wollen, weil die Komponentenbibliothek die Prompt-Grundlage bildet. Wer eine reine Textausgabe braucht oder keine Streaming-Pipeline betreiben will, ist hier falsch. Vor der Adoption sollte man den Scaffold unter npx @openuidev/cli@latest create --name genui-chat-app ausführen, die generierte System-Prompt-Datei lesen und prüfen, ob die Prompt-Generierung aus der eigenen Komponentenbibliothek die gewünschten Komponenten überhaupt abdeckt. Ohne diesen Blick auf den erzeugten Prompt bleibt unklar, was das Modell tatsächlich zu sehen bekommt.

Offizielle Quellen

1. Issues
2. License: MIT
3. Project website
4. README
5. thesysdev/openui on GitHub