Symfony Tui: Was die neue Terminal-Komponente wirklich kann

Wer heute PHP-CLI-Tools für Agenturen baut, weiß: Interaktive Terminals sind mit dem Console-Komponent möglich, aber nie elegant. Progress-Bars, Tabellen, farbige Ausgaben, das geht. Echte Widgets, Layout-Management, Maus-Unterstützung, Echtzeit-Rendering, das geht nicht. Nicht ohne externes Tooling, nicht ohne ANSI-Escape-Sequenzen von Hand, nicht ohne Performance-Kompromisse.

Fabien Potencier hat am 25. März 2026 die neue Symfony-Tui-Komponente angekündigt und den Pull Request auf github.com/symfony/symfony geöffnet. Heute, am zweiten Tag von SymfonyOnline June 2026, präsentiert er sie live unter dem Titel "Building TUIs in PHP: The Symfony Terminal Component".

Wenn Sie meinen ersten TUI-Artikel gelesen haben: Das hier ist die technische Vertiefung. Architektur, Code-Konzepte, Grenzen und die Frage, wann es sich lohnt, Tui einzusetzen.

Was macht Tui anders als Console?

Die Trennung ist konsequent: Console bleibt für alles, was mit CLI-Struktur zu tun hat. Tui übernimmt alles, was mit reichhaltiger Terminal-Interaktion zu tun hat. Wer beide kombiniert, schreibt einen normalen Symfony-Console-Command, der am Ende seiner execute()-Methode eine Tui-Session startet.

Was steckt unter der Haube?

PHP Fibers + Revolt: Nebenläufigkeit ohne Extensions

Das technisch Bemerkenswerteste an Tui ist die Nebenläufigkeits-Architektur. Unter der Haube laufen PHP Fibers und der Revolt Event Loop, voll nebenläufig, single-threaded, ohne Extensions, ab PHP 8.4.

Was das konkret ermöglicht: Animationen laufen weiter, während Tastatureingaben verarbeitet werden. Der Loader-Spinner dreht sich während eines HTTP-Requests. Input wird nie durch Rendering blockiert. Mehrere asynchrone Operationen laufen parallel. Das Amp-Ecosystem liefert non-blocking Alternativen für HTTP, Prozesse und Timer, die nahtlos integriert werden, weil sie denselben Event Loop teilen.

Für PHP-Entwickler, die Fibers bisher nur theoretisch kennen: Tui ist eines der ersten Praxis-Beispiele, wie Fibers eine ganze UI-Engine tragen können. Wie ich im Artikel zu PHP True Async beschrieben habe, verschiebt sich mit PHP 8.4 die Grenze dessen, was single-threaded PHP leisten kann. Tui zeigt das konkret.

// Tui läuft als Fiber in einem Console-Command
class MonitorCommand extends Command
{
    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $tui = new Tui(new TerminalScreen());

        // Widget-Baum aufbauen
        $dashboard = new ContainerWidget([
            new TextWidget('Server-Monitor'),
            new ProgressBarWidget(id: 'cpu'),
            new SelectListWidget(id: 'processes'),
        ]);

        $tui->setRoot($dashboard);

        // Fiber startet, rendern läuft, bis Escape gedrückt wird
        return $tui->run();
        // Terminal wird danach automatisch wiederhergestellt
    }
}

Retained Mode: Was das für die Performance bedeutet

Tui nutzt einen Retained-Mode-Renderer statt manuellem Zeilen-Redraw. Der Unterschied ist fundamental: Im Immediate Mode (wie viele Terminal-Libs ihn implementieren) wird bei jeder Änderung der gesamte Screen neu gezeichnet. Im Retained Mode verwaltet das Framework den Widget-Baum, erkennt was sich geändert hat, und zeichnet nur die geänderten Teile neu.

Drei Mechanismen arbeiten zusammen:

Dirty-Tracking: Widgets self-invalidieren, wenn sich ihr Zustand ändert. Nur Widgets im Dirty-Zustand werden im nächsten Frame neu gerendert.

Render-Cache: Unveränderte Widgets geben ihren gecachten Output zurück, ohne Style-Auflösung, Layout, oder Content-Rendering zu wiederholen.

Screen-Diffing: Vor dem Schreiben in den Terminal wird der neue Frame mit dem vorherigen verglichen. Nur geänderte Zeichen werden übertragen, das minimiert den I/O-Traffic erheblich.

Das Ergebnis: Smooth rendering, efficient enough for real-time games.

Das Widget-System und CSS-artiges Styling

Tui liefert ein vollständiges Widget-Toolkit: TextWidget für Labels und FIGlet ASCII-Art, InputWidget für Textfelder mit Cursor und Paste-Support, EditorWidget für mehrzeiligen Text mit Undo/Redo und Autocomplete, SelectListWidget für filterbare Listen, MarkdownWidget mit CommonMark-Support und Syntax-Highlighting, ProgressBarWidget und LoaderWidget für Hintergrund-Operationen.

Das Styling-System ist bewusst an CSS angelehnt. Es gibt drei Wege:

# 1. Stylesheet-Rules mit CSS-artigen Selektoren:
$stylesheet->addRule('.sidebar:focused', new Style(
    border: Border::all(1, 'rounded', 'cyan'),
));

# 2. Tailwind-artige Utility-Klassen:
$widget->addStyleClass('p-2 bg-emerald-500 bold border-rounded');
# Volle Tailwind-Shade-Palette: text-blue-700, bg-rose-100, ...

# 3. Inline-Styles für One-off-Overrides

# Responsive Breakpoints für terminal-width-basierte Layouts:
$stylesheet->addRule('@small .sidebar', new Style(hidden: true));

Für Symfony-Entwickler, die Twig kennen: Es gibt auch Twig-Templates für die Widget-Struktur (als Follow-up PR). Struktur in Templates, Styling in Stylesheets, Verhalten in PHP. Dieselbe Separation of Concerns wie in der Web-Entwicklung, nur für das Terminal.

Was sind die realen Use-Cases?

Welche Projekte profitieren von Tui jetzt?

Fabien Potencier hat Tui bereits in einem eigenen KI-Coding-Agent eingesetzt: Editor-Widget für Code-Input, Markdown-Rendering für KI-Responses, Streaming-Output via Fibers, Overlays für Modell-Auswahl, Tabs für mehrere Konversationen. Das zeigt den Anspruch: Tui ist kein Toy, sondern produktionsreif für komplexe Terminal-Applikationen.

Für Agenturen und PHP-Teams sind drei Kategorien sofort relevant:

Lokale Monitoring-Dashboards: Docker-Status, Server-Logs, Test-Runner-Ergebnisse. Alles, was bisher im Browser-Dashboard lief, aber eigentlich im Terminal sein sollte.

Interaktive Installer und Setup-Wizards: Projektinitialisierung, Environment-Konfiguration, Datenbank-Migration. Mit SelectList, Input-Widgets und Progress-Bars statt endloser Fragelisten per $io->ask().

Deployment- und DevOps-Tools: Echtzeit-Status von mehreren Services, parallel laufende Deployments, Cancel-Button für länger laufende Prozesse. Alles was die Fiber-Architektur ermöglicht.

Was sind die Grenzen?

Tui ist experimentell und nicht von Symfonys BC-Promise abgedeckt. Breaking Changes zwischen Versionen sind möglich. Als Symfony-Entwickler, der regelmäßig neue Komponenten evaluiert, ist das der wichtigste Vorbehalt: Wer heute eine Produktions-Applikation auf Tui aufbaut, muss mit Änderungen rechnen.

Was die Dokumentation nicht explizit benennt: Einige Features sind noch als Follow-up PRs markiert (Maus-Support, Twig-Templates, Overlay-Widget, Tabs, AnimatedImageWidget). Der aktuelle Stand ist der Kern, nicht das vollständige Feature-Set. Das ist kein Kritikpunkt, sondern eine Einschätzungshilfe für die Projekt-Planung.

Für Teams, die PHP-Erfahrung mit Fibers haben: Der Revolt Event Loop ist der richtige Ansatz, aber er erfordert ein anderes Denken als synchrones PHP. Nicht jeder PHP-Entwickler ist mit dem Event-Loop-Modell vertraut.

Aus der Praxis: CLI-Tools in deutschen Agentur-Projekten

Der häufigste Anti-Pattern: Teams bauen komplexe interaktive CLI-Tools mit der Console-Komponente und landen bei ANSI-Escape-Sequenzen von Hand, weil die Console-Abstraktion nicht weit genug geht. Tui ist die Antwort darauf. Aber erst dann, wenn die Komponente aus dem experimentellen Status heraus ist, sollte sie in geschäftskritischen Tools eingesetzt werden.

Zusammenfassung

Symfony Tui trennt konsequent Terminal-UI-Aufgaben von der Console-Komponente. Widgets, Layouts, CSS-artiges Styling, Maus-Support, Echtzeit-Rendering.

PHP Fibers + Revolt Event Loop ermöglichen echte Nebenläufigkeit ohne Extensions, ab PHP 8.4. Animationen laufen während Rendering, HTTP-Requests blockieren nicht.

Retained-Mode-Renderer mit Dirty-Tracking, Render-Cache und Screen-Diffing macht Tui effizient für Echtzeit-Applikationen.

Experimenteller Status: Kein BC-Promise. Für interne Tools und Prototypen jetzt ideal. Für Produktions-Applikationen: warten.

Use-Cases: Lokale Monitoring-Dashboards, interaktive Installer, Deployment-Tools mit Echtzeit-Status.