Warum PHP jetzt echte Terminal-Interfaces bekommt
Heute vor wenigen Stunden hat Fabien Potencier auf der SymfonyLive Paris 2026 ein komplett neues Symfony-Component angekündigt und den Pull Request live auf der Bühne geöffnet: Symfony TUI (Text User Interface). Das ist kein inkrementelles Update der Console-Component. Das ist ein vollständiges Framework für interaktive Terminal-Anwendungen mit Widgets, Layouts, CSS-artiger Stil-Engine, Maus-Support und Event-System.
Ein neues Symfony-Component ist ein seltenes Ereignis. Das letzte grundlegend neue Component war Mailer 2019. TUI ersetzt nicht Console, sondern erweitert das Ökosystem um eine Kategorie, die PHP bisher nicht hatte: Echte Terminal User Interfaces, vergleichbar mit Ink (React), Bubble Tea (Go) oder Charm (Rust).
Ich habe die Ankündigung remote verfolgt und mir den Pull Request sowie Fabiens Slides angesehen. In diesem Artikel ordne ich ein, warum dieses Component relevant ist, welche Architektur dahinter steckt und wo die praktischen Use Cases liegen. Keine fiktiven Beispiele, sondern eine fundierte Analyse aus Entwickler-Perspektive.
Das Problem: Console Component kann keine echten UIs
Die Symfony Console-Component ist eines der meistgenutzten Components im PHP-Ökosystem. Composer, Symfony CLI, Doctrine Migrations, Laravel Artisan, Shopware CLI und hunderte andere Tools bauen darauf. Aber Console war nie für interaktive UIs gedacht.
Console macht Commands gut: Argumente parsen, Optionen definieren, Ausgabe formatieren, Progress Bars rendern. Was Console nicht kann: Echtzei t-Interaktion, komplexe Layouts, Event-gesteuerte Interfaces, mehrere gleichzeitig sichtbare Widgets.
Ein konkretes Beispiel: Ein Installer-Tool, das gleichzeitig zeigen soll:
- Einen Progress-Indikator für den aktuellen Schritt
- Ein Log-Fenster mit scrollbaren Meldungen
- Eine Konfigurationsansicht mit editierbaren Feldern
- Einen Status-Footer mit Keyboard-Shortcuts
Mit Console geht das nicht. Man kann sequenziell Fragen stellen (SymfonyStyle), eine Progress Bar zeigen oder eine Tabelle ausgeben. Aber alles nur linear, nie parallel.
Aus meiner Erfahrung mit CLI-Tool-Entwicklung: Die meisten Symfony-Commands sind reine Batch-Prozesse, keine interaktiven Anwendungen. Nicht weil Entwickler das nicht wollen, sondern weil Console die Werkzeuge dafür nicht liefert. TUI ändert das fundamental.
Die Lösung: Ein vollständiges Widget-Toolkit für das Terminal
Symfony TUI ist kein CLI-Helper. Es ist ein UI-Framework für das Terminal mit einer Architektur, die man aus Web-Entwicklung kennt: Widgets, Layouts, Stylesheets, Events.
Widget-System: Vom Text bis zum Multi-Line-Editor
TUI liefert ein komplettes Widget-Repertoire:
- TextWidget: Labels, Headings, FIGlet ASCII-Art-Banner
- InputWidget: Single-Line Text-Felder mit Cursor, Scrolling, Paste-Support
- EditorWidget: Multi-Line Text-Editor mit Word-Wrap, Undo/Redo, Kill-Ring, Autocomplete
- SelectListWidget: Scrollbare, filterbare Auswahllisten
- SettingsListWidget: Preference-Panels mit Value-Cycling, Submenüs
- TabsWidget: Multi-View-Interfaces mit horizontalen/vertikalen Tabs (follow-up PR)
- MarkdownWidget: Vollständige CommonMark-Unterstützung mit Syntax-Highlighting
- ImageWidget/AnimatedImageWidget: Inline-Images (Kitty-Protokoll), GIF-Playback als ASCII-Art (follow-up PR)
- OverlayWidget: Modale Dialoge, Dropdowns, Floating-Panels (follow-up PR)
- LoaderWidget, ProgressBarWidget: Hintergrund-Operationen mit Fortschrittsanzeige
Jedes Widget unterstützt Padding, Borders (9 Built-in-Patterns wie rounded, double), Backgrounds, Text-Decoration, Alignment. Widgets komponieren sich in Bäume über ContainerWidget mit vertikalem/horizontalem Layout, Gaps, vertikaler Expansion.
Das ist nicht "ein paar Helper-Funktionen". Das ist ein vollständiges UI-Toolkit.
CSS-artiges Style-System: Cascade, Breakpoints, Utility-Classes
Die Style-Engine ist direkt von CSS inspiriert. Styles sind immutable Value Objects mit Properties für Farben, Text-Formatting, Padding, Borders, Layout-Direction, Gaps, Alignment.
Drei Wege, Widgets zu stylen:
1. Stylesheet-Rules mit CSS-like Selektoren:
$stylesheet->addRule('.sidebar:focused', new Style(
border: Border::all(1, 'rounded', 'cyan'),
));
$stylesheet->addRule(MarkdownWidget::class.'::code-block-border', new Style(
color: 'gray',
));Selektoren unterstützen: Universal (*), FQCN, Class, State, Sub-Elements, Responsive Breakpoints.
2. Tailwind-like Utility-Classes:
$widget->addStyleClass('p-2');
$widget->addStyleClass('bg-emerald-500');
$widget->addStyleClass('bold');
$widget->addStyleClass('border-rounded');Vollständige Tailwind-Shade-Palette: text-blue-700, bg-rose-100, border-cyan-400.
3. Inline-Styles für One-Off-Overrides:
Die Cascade merged diese Layer genau wie CSS: Stylesheet-Rules, dann Utility-Classes, dann Inline-Styles. Responsive Breakpoints funktionieren wie @media-Queries: Layout wechselt basierend auf Terminal-Breite.
Was die offizielle Ankündigung nicht explizit betont: Das CSS-Modell ist bewusst gewählt, um Web-Entwicklern den Einstieg zu erleichtern. Wer Tailwind nutzt, versteht TUI-Styling sofort.
Deklarative Templates mit Twig (follow-up PR)
TUI bringt ein Template-System, das Widget-Bäume als Pseudo-HTML in Twig beschreibt:
{% extends "layout.html.twig" %}
{% block content %}
<text>Pick a language:</text>
<select-list id="list" max-visible="5">
<item value="php" label="PHP" description="Hypertext Preprocessor"></item>
<item value="python" label="Python" description="Simple and powerful"></item>
<item value="rust" label="Rust" description="Memory safety without GC"></item>
</select-list>
{% endblock %}Templates unterstützen Twig-Inheritance, Blocks, Loops, Conditionals, Custom Widget-Tags via Namespace-Prefixes. Das ist Separation of Concerns wie in Web-Dev: Twig für Struktur, Stylesheets für Presentation, PHP für Behavior.
Architektur: PHP Fibers, Revolt Event Loop, Dirty Tracking
TUI läuft auf PHP Fibers (PHP 8.4+) und der Revolt Event Loop. Das bedeutet: Single-threaded, aber fully concurrent. Keine Extensions nötig, pure PHP.
Was Fibers ermöglichen: Non-Blocking UIs
Mit Fibers können Animationen weiterlaufen, während der User tippt. Loader-Spinner drehen sich während HTTP-Requests. Input wird nie durch Rendering blockiert. Mehrere async Operationen laufen parallel.
Das Amp-Ökosystem liefert non-blocking Replacements für HTTP, Processes, Timer, die nahtlos integrieren (shared event loop). Das ist ein massiver Architektur-Vorteil gegenüber traditionellen PHP-CLIs.
Aus der Praxis: Ich habe Worker-Prozesse gesehen, die blocking I/O machen und während langer Requests keine UI-Updates zeigen können. Mit TUI ist das Geschichte.
Smart Rendering: Dirty Tracking, Cache, Screen Diffing
Die Rendering-Pipeline ist performance-optimiert:
- Dirty Tracking: Widgets markieren sich selbst als dirty, nur dirty Subtrees werden re-renderd
- Render Cache: Unveränderte Widgets geben cached Output zurück, überspringen Style-Resolution, Layout, Content-Rendering komplett
- Screen Diffing: Nur geänderte Terminal-Zellen werden geschrieben, minimiert I/O
- Compositing: Mehrere Layer (transparent/opaque) können gemerged werden (für animierte Backgrounds mit Text drüber)
Fabien schreibt im Announcement: "Smooth rendering, efficient enough for real-time games." Das ist keine Marketing-Phrase. Die Architektur ist darauf ausgelegt.
Mouse-Support, Focus-Management, Keybindings
TUI liefert das komplette Interaction-Pattern-Set:
- Mouse-Support (follow-up PR): Click to focus, Click to place cursor, Scroll wheels, Drag, Click-outside-Dismissal. Shift-Hold bypassed Mouse-Tracking für native Text-Selection
- Focus-Management: F6/Shift+F6 Cycling, programmatic Focus,
:focused-State für conditional Styling - Customizable Keybindings: Three-Layer-Merge (Widget-Defaults, App-Level, Per-Widget-Overrides). Remap ohne Subclassing
- Event-System: Symfony EventDispatcher, per-Widget-Listener, global Listener, typed Events (
SubmitEvent,SelectEvent,ChangeEvent,CancelEvent,TabChangeEvent,FocusEvent)
Das ist State-of-the-Art UI-Engineering. Vergleichbar mit modernen Web-Frameworks, nur für das Terminal.
Die Integration in bestehende Symfony-Console-Architekturen erfordert strategische Planung, besonders für Tools, die beide Components kombinieren wollen. Lassen Sie uns das gemeinsam evaluieren.
Praxis-Perspektive: Wo ist TUI tatsächlich relevant?
Nach dem Review der Ankündigung und des Pull Requests sehe ich vier Kategorien von Anwendungen, die massiv profitieren.
CLI-Tools und Installer: Interaktive UIs statt Fragebögen
Symfony-Installer, Composer-Installer, Doctrine-Setup-Tools und Custom-Deployment-Scripte nutzen aktuell SymfonyStyle für sequenzielle Fragen. Mit TUI können diese Tools echte UIs haben:
- Multi-Step-Wizard mit sichtbarem Fortschritt
- Live-Validierung während der Eingabe
- Kontextuelle Hilfe in Side-Panels
- Undo/Redo für Konfigurationsschritte
Das erhöht nicht nur UX, sondern reduziert Fehler. User sehen sofort, wenn eine Eingabe invalide ist, statt nach Submit zu crashen.
Monitoring-Dashboards: Echtzeit-Daten statt Log-Tailing
Symfony-Profiler-CLI, Doctrine-Migration-Status, Queue-Worker-Monitoring und Custom-Metrics-Tools sind aktuell statisch. Mit TUI werden diese zu Live-Dashboards:
- Multi-Panel-Layouts (Request-Graph, Error-Log, Performance-Metrics parallel)
- Auto-Refresh mit Fiber-based Polling
- Filterable Logs mit Scroll-Support
- Interactive Drilldowns (Click auf Request zeigt Details)
Aus meiner Projekterfahrung: Entwickler verbringen Stunden mit tail -f und Log-Grep. Ein interaktives Dashboard mit Markdown-formatierten Logs und Syntax-Highlighting ist ein Game Changer.
AI-Agent-Interfaces: Streaming-Output mit Context-Panels
Fabien erwähnt im Announcement: TUI powered bereits seinen eigenen AI-Coding-Agent. Das ist kein Zufall. AI-Agents brauchen:
- Streaming-Output (Markdown-Widget mit Live-Rendering)
- Code-Editor (EditorWidget mit Syntax-Highlighting, Autocomplete)
- Conversation-History (Tabs für Multiple Conversations)
- Model-Selection (Overlay-Widget für Dropdowns)
- Customizable Keybindings (User-defined Shortcuts für häufige Actions)
Das sind alles Built-in-Features von TUI. Für AI-Tooling ist TUI perfekt.
Developer-Tools und REPLs: Richer Interactive Shells
PHP REPL (PsySH), Symfony Console REPL, Custom-Debug-Tools und Test-Runners können mit TUI zu richtigen IDEs im Terminal werden:
- Split-Screen (Code-Editor links, Output rechts)
- Autocomplete mit Dropdown-Listen
- Variable-Inspector mit Tree-Views
- Stack-Trace-Navigation mit Click-Support
PsySH mit TUI-Frontend wäre eine vollwertige Terminal-IDE.
Vergleich mit anderen Ökosystemen: PHP holt massiv auf
TUI-Frameworks existieren in anderen Sprachen seit Jahren:
- Ink (React/JavaScript): React-Components im Terminal, seit 2017
- Bubble Tea (Go): Elm-Architecture für Terminal-Apps, seit 2020
- Ratatui (Rust): Widget-basiertes TUI-Framework, seit 2016 (als tui-rs)
- Textual (Python): CSS-artiges Styling, Widget-System, seit 2021
PHP hatte bisher nichts Vergleichbares. Symfony TUI bringt PHP auf Augenhöhe mit diesen Ökosystemen.
Was TUI besonders macht: Die Integration ins Symfony-Ökosystem. Console-Commands können TUI-Interfaces launchen und danach normal Console-Output nutzen. DI-Container, EventDispatcher, Twig und Amp sind bereits dabei. Das ist kein Standalone-Framework, sondern Teil eines größeren Ganzen.
Strategische Empfehlungen: Wie bereitet man sich vor?
TUI ist für Symfony 8.1 geplant (Release Ende 2026). Der Pull Request wurde heute geöffnet, Review läuft. Bis zum produktiven Einsatz vergehen Monate. Aber die Vorbereitung kann jetzt beginnen.
Kurzfristig: Bestehende CLI-Tools analysieren
Identifiziere Tools, die von interaktiven UIs profitieren würden:
- Installer mit vielen Schritten: Würde Multi-Step-Wizard helfen?
- Monitoring-Scripts mit Polling: Würde Live-Dashboard UX verbessern?
- Complex Configuration-Tools: Würde Settings-List mit Live-Preview helfen?
Nicht jedes CLI-Tool braucht TUI. Batch-Prozesse, Single-Purpose-Scripts, Cron-Jobs sind mit Console besser bedient. TUI ist für interaktive Anwendungen.
Mittelfristig: Fiber-Architektur verstehen
TUI nutzt PHP Fibers (PHP 8.4+). Wenn Ihr Projekt aktuell auf PHP 8.2 oder 8.3 läuft, plant den Upgrade-Path. Fibers sind nicht backward-compatible mit Generators oder Threading.
Investiert Zeit in Revolt Event Loop. TUI ist non-blocking, aber das bedeutet auch: Blocking I/O (file_get_contents, mysqli_query ohne async Wrapper) blockiert die gesamte UI. Amp-Replacements (amphp/http-client, amphp/mysql) sind Pflicht für Production-UIs.
Langfristig: Hybrid-Ansatz Console + TUI
TUI ersetzt Console nicht. Beide Components existieren parallel. Die Strategie:
- Console für: Batch-Jobs, CI/CD-Scripts, Non-interactive Commands
- TUI für: Interactive Tools, Monitoring, Developer-UIs, AI-Agents
- Hybrid: Console-Command startet TUI-Interface, returniert Exit-Code
Fabien zeigt im Announcement: Tui wird in Command::execute() erstellt, gerunned, Terminal wird restored, Console-Output funktioniert danach normal. Das ist seamless Integration.
Aus Sicht eines Symfony-Entwicklers: Das wird CLI-Tool-Design fundamental verändern. Mehr Interaktivität, bessere UX, höhere Erwartungen an Developer-Tools.
Ausblick: Was kommt als nächstes?
Der Pull Request wurde heute geöffnet. Stand 26. März 2026, 12 Uhr: Status ist "Needs Review", Milestone ist Symfony 8.1.
Fabien hat mehrere Features als "follow-up PR" markiert:
- TabsWidget: Multi-View-Interfaces (horizontal/vertikal)
- OverlayWidget: Modale Dialoge, Dropdowns, Floating-Panels
- Mouse-Support: Click, Drag, Scroll-Wheels
- ImageWidget/AnimatedImageWidget: Inline-Images, GIF-Playback
- Twig-Template-System: Deklarative Widget-Bäume
Das sind keine Optional-Add-Ons, sondern geplante Core-Features. Sie wurden aus dem Initial-PR gezogen, um Review zu beschleunigen.
Für Symfony-Adopter bedeutet das: Symfony 8.1 Beta (Mitte 2026) wird experimentellen TUI-Support haben. Symfony 8.1 Stable (Ende 2026) wird Production-Ready sein.
Parallel laufen Diskussionen über:
- TUI-Bundle für Symfony Framework: Auto-Configuration, DI-Integration
- Console-Migration-Guide: Best Practices für Console-zu-TUI-Umstellung
- Community-Widgets: Third-Party-Widget-Packages
Die Community-Response ist überwältigend positiv. Der Pull Request hat in 2 Stunden 13 Hooray-Reactions, 4 Hearts, 1 Rocket. Das ist ungewöhnlich für ein neues Component.
Zusammenfassung: Drei Key Takeaways
1. TUI ist ein vollständiges UI-Framework, keine Console-Extension: Widgets, Layouts, CSS-artiges Styling, Events, Mouse-Support, Fibers-based Rendering. Das ist State-of-the-Art Terminal-Engineering.
2. Die Architektur ist Production-Ready: Fabien nutzt TUI bereits für seinen AI-Agent. Smart Rendering, Dirty Tracking, Screen Diffing und non-blocking I/O sind eingebaut.
3. Das ändert CLI-Tool-Entwicklung fundamental: Installer werden Wizards, Monitoring-Scripts werden Dashboards, REPLs werden Terminal-IDEs. PHP-CLI-Tools holen auf zu modernen TUI-Frameworks in anderen Sprachen.
Dieser Announcement kommt direkt von Fabien Potencier, dem Symfony-Gründer. Das ist kein Experiment, sondern strategische Weiterentwicklung des Ökosystems. Wer CLI-Tools entwickelt, sollte TUI auf dem Radar haben.
Professionelle Beratung: Symfony-Architektur für Ihr Projekt evaluieren
Neue Symfony-Features wie TUI zeigen, wohin sich das Ökosystem entwickelt. Aber die Frage für Ihr Projekt ist: Welche Symfony-Komponenten bringen tatsächlich Mehrwert? Nicht jedes neue Feature muss genutzt werden.
Als Symfony-Entwickler mit Fokus auf API-Architekturen und Backend-Lösungen für kleine Agenturen und KMU unterstütze ich Sie bei der strategischen Einordnung: Welche Symfony-Updates sind relevant für Ihre Infrastruktur? Wo liegen die konkreten Geschäftsvorteile? Welche Modernisierungen haben Priorität?
Lassen Sie uns in einem Erstgespräch Ihre Symfony-Architektur analysieren. Ich zeige Ihnen, welche Technologien zu Ihrem Projekt passen und wo Investitionen sinnvoll sind.
Jetzt Erstgespräch vereinbaren
Über den Autor: Dennis Schwenker-Sanders ist PHP & Symfony-Entwickler mit Fokus auf API-Architekturen, Backend-Lösungen und moderne Symfony-Patterns. Er unterstützt kleine Agenturen und KMU-Technikteams bei der Evaluierung und Implementierung von Symfony-basierten Projekten. Mehr über Dennis