Warum TUIs zurück sind

• TUIs rücken wieder in den Fokus, weil sie sofortiges Feedback, einfache Automatisierung und Betriebssystem-übergreifende Nutzbarkeit bieten; auch Tools wie Claude und Codex sind auf der Kommandozeile sehr erfolgreich
• Native GUIs unter Windows, Linux und macOS belasten Entwickler und Nutzer gleichermaßen, weil API-Strategien instabil sind, Toolkits und Umgebungen zersplittert sind und die Konsistenz mit früheren Richtlinien nachgelassen hat
• Bei Electron-Apps ist weniger der Speicherverbrauch als vielmehr die mangelnde visuelle Konsistenz und die Lücken in keyboard-zentrierten Workflows das größere Problem; auch die Integration von Menüs und Shortcuts ist schwächer geworden
• Es gab Bestrebungen, neue UI-Stacks zu bauen, etwa mit Googles Flutter UI oder Zeds GPUI, doch ohne ausreichende Integration ins Betriebssystem reicht selbst ein schneller Renderer nicht aus
• Der Kern guter Interfaces ist Konsistenz, damit Nutzer weniger nachdenken müssen; Entwickler sowie Betriebssystem- und Toolkit-Hersteller sollten stärker in UI-Theorie und gut zugängliche Toolkits investieren

---

Warum TUIs wieder Aufmerksamkeit bekommen

• DHHs Omarchy besteht aus einer Mischung aus TUI, Web-App und nativen Apps im Gnome-Stil; die TUI wird für sofortiges Feedback und „geek points“ eingesetzt
• Einen ähnlichen Trend gab es schon vor etwa 10 Jahren bei Code-Editoren
  • Man wechselte von nativen Editoren wie BBEdit, Textmate, Notepad++ und Sublime zu Electron-basierten Apps wie Atom, VSCode und deren Ablegern
  • Nutzer mit starken Präferenzen wanderten zu vim oder emacs ab und erhielten dafür sofortiges Feedback und hohe Nutzbarkeit, mussten aber eine sehr steile Lernkurve in Kauf nehmen

Warum native GUIs schwächer geworden sind

• Windows

  • Windows konnte keine konsistente Strategie für GUI-Bibliotheken etablieren und wiederholte immer wieder das Muster, bei ausbleibendem Erfolg einer API einfach die nächste zu schaffen
  • Jeffrey Snover schrieb in Microsoft hasn’t had a coherent GUI strategy since Petzold, dass MFC, OLE, COM und ActiveX Komplexität über die gesamte Windows-Entwicklung verteilt hätten
  • Microsoft ging später über WinForms, WPF, Silverlight, WinUI und MAUI, hatte damit aber keinen Erfolg; viele Enterprise- und Consumer-Desktop-Apps sind weiterhin auf Electron angewiesen
  • Die letzte Phase, in der Windows als Ganzes visuell konsistent integriert wirkte, war eher Windows 98 oder Windows 2000
  • Domenic Denicola sieht in Windows Native App Development Is a Mess die Kosten dafür als hoch an, das OS und die UI-API alle paar Jahre neu zu bauen; dazu kämen Sandboxing und der Versuch, Features auszumustern, wodurch in jeder neuen Schicht Lücken entstünden, in denen Dinge nicht mehr möglich seien, die im vorherigen Framework gingen

• Linux

  • Die Uneinheitlichkeit der Linux-UIs ist eher ein Resultat des Designs selbst; verschiedene Teams hatten die Freiheit, unterschiedliche Ziele zu verfolgen
  • GTK und Qt wurden zu den wichtigsten Frameworks, beide mit dem Anspruch auf plattformübergreifende native Entwicklung, tatsächlich aber vor allem auf Linux weit verbreitet
  • Linux-Apps aus unterschiedlichen Toolkits können nebeneinander noch einigermaßen stimmig wirken, während mehrere Windows-Frameworks dieses Maß an Harmonie nicht erreichen
  • Weil es zu viele Kombinationen aus Distributionen, Desktop-Umgebungen und Hardware gibt, ist Testen schwierig; daher bauen viele Unternehmen keine nativen Linux-Apps
  • Firmen unterstützen Linux meist über Electron oder überlassen die Lösung direkt der Open-Source-Community, wenn es eine öffentliche API gibt

• macOS

  • Apples Human Interface Guidelines galten als so starke Referenz, dass sie in UI-Kursen weltweit zitiert wurden
  • Xerox PARC und Apple gelten als prägende Institutionen in der Forschung dazu, was gute Human Interfaces ausmacht
  • In jüngerer Zeit bewegt sich Apple jedoch in eine Richtung, die die Konsistenz früherer Richtlinien aufbricht
  • macOS ignoriert Fitts’ Law, macht das Ändern der Fenstergröße nahezu unmöglich, behält die Probleme trotz Korrekturversuchen bei und fügt allen Menüs Icons hinzu
  • macOS lässt sich kaum noch als sicherer Rückzugsort betrachten, in dem Designer in Ruhe arbeiten können

Grenzen von Electron-Apps

• Das am häufigsten genannte Problem ist der Speicherverbrauch, doch dieser ist in den vergangenen 10 Jahren tendenziell gesunken
• Das größere Problem ist die mangelnde visuelle Konsistenz und das Fehlen keyboard-zentrierter Arbeitsabläufe
• Selbst auf einem MacBook Pro mit 64 GB RAM liegen im Dock 8 native Apps neben 6 Electron-Apps
  • Native Apps: TextMate und macOS-Systemwerkzeuge
  • Electron-Apps: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
• In Apps wie Cursor und VSCode ist es nicht natürlich, nach einer Funktionsanfrage im Agent-Panel allein per Tastatur zur Agentenliste in der Seitenleiste zu wechseln oder Elemente dort zu archivieren
• Solche Aktionen sollten in allen macOS-Apps auf dieselbe Weise möglich sein, doch selbst wenn es Shortcuts gibt, werden sie manchmal nicht im Menü angezeigt
• In den vergangenen 10 Jahren haben Entwickler zunehmend vergessen, Aktionen, die in Apps möglich sind, auch in Menüs aufzunehmen; das hängt mit einer Struktur zusammen, in der Anwendungen als HTML in einer Sandbox implementiert werden
• Slack geht mit diesen Punkten besser um als andere Electron-Apps, ist aber nicht perfekt

Versuche, neue UI-Stacks neu aufzubauen

• Google wollte zusammen mit Dart ein UI-Toolkit für ein neues Betriebssystem und neue Geräte ohne Android-Altlasten schaffen
• Google wollte ein neues UI-Toolkit namens Flutter UI, gab das Projekt aber auf, bevor ein reales Produkt erschien
• Solche Versuche können nur mit monopolähnlicher Stellung oder ausreichend großem Marktanteil erfolgreich sein
• Zed schlug mit Rust einen ähnlichen Weg ein und baute mit GPUI eine eigene GPU-Renderer-Bibliothek, die auf Plattformübergreifung abzielt
• GPUI ist schnell, bietet aber für sich genommen nicht genug Integration mit dem Host-Betriebssystem, sodass Entwickler die nötigen Bindings selbst ergänzen müssen
• Ein langsamerer Renderer mit guter Betriebssystem-Integration ist besser als ein schneller Renderer ohne sie

Die Lücke, die TUI füllt

• Vor dem Hintergrund, der an den Niedergang von Apple Automator erinnert, wird TUI wieder als automatisierbares Interface wichtig
• TUI lässt sich auch relativ einfach remote ausführen und ist nicht auf das kopfschmerzerzeugende X forwarding angewiesen
• Wenn native UI-Toolkits scheitern, kehrt man zu den Grundlagen zurück, und dadurch wird TUI wieder zu einer Option
• Claude und Codex sind auf der Kommandozeile sehr erfolgreich, und Nutzer können sich stärker auf die Interaktion selbst konzentrieren statt auf das umgebende Betriebssystem
• Über TUIs lassen sich Code und Apps auf Cloud-Maschinen bedienen oder von einem iPad aus per Remote-Zugriff auf Maschinen mit GPU zugreifen
• TUI füllt die Lücke, die Apple und Microsoft in einer Welt hinterlassen haben, in der jede Anwendung anders aussieht
• Unterschiedliche Erscheinungsbilder mögen für Kunst oder Computerspiele gut sein, sind aber ungeeignet für das Ziel, dass sich ein Interface zurücknimmt, damit Nutzer ihre eigentliche Arbeit erledigen können

Welche Richtung jetzt nötig ist

• John Loeber argumentiert in Bring Back Idiomatic Design, dass selbst eine Checkbox ein Interface zur Interaktion mit einem System ist und ein gutes Interface Nutzer weniger nachdenken lässt
• Nutzer interagieren mit vielen Dingen, daher brauchen sie homogene Interfaces, die eine konsistente Erfahrung schaffen
• Wenn Command+C der Shortcut zum Kopieren ist, sollte er überall funktionieren; stattdessen in bestimmten Situationen CTRL+Shift+C oder Rechtsklick → Kopieren gesondert merken zu müssen, ist unpraktisch
• Alle Entwickler sollten nicht nur Softwareentwicklung lernen, sondern auch die Theorie guter Benutzeroberflächen
  • Nielsen
  • Norman
  • Johnson
• Die Haltung, User Design in der Software-Engineering-Ausbildung als unwichtige Soft Skill zu behandeln, muss enden
• In jedem Ausbildungsgang sollte ein Projekt als gescheitert gelten, wenn die UI nicht verstanden wird; in HCI-Kursen sollte das Ziel eine perfekte UI sein
• Der Großteil der Arbeit an guter UI steckt im Verstehen der Anforderungen; das Programmieren selbst wird bereits automatisiert
• Betriebssystem- und Toolkit-Hersteller sollten Investitionen in gut zugängliche Toolkits vorantreiben, die Entwickler wirklich verwenden wollen, und die Einstiegshürden senken
• Es geht nicht darum, plattformübergreifende Unterstützung zwingend zu fordern, aber schon eine einzige solche Lösung könnte helfen, die Abhängigkeit von Electron und TUI zu verringern

[colus001]

Ich sehe das ähnlich: Die Entwicklerszene ist meiner Meinung nach übermäßig trendsensibel. TUI wird letztlich nur von Unternehmen vorangetrieben, die entweder nicht in der Lage sind oder nicht den Willen haben, eine ordentliche GUI zu bauen; ich frage mich, wie viele Menschen TUI tatsächlich nutzen.

[GN⁺]

Meinungen auf Lobste.rs

• Ich wünschte, die Leute würden lieber native Apps bauen. TUIs wirken wie eine Kombination aus den Nachteilen von Kommandozeilen-Interfaces und echten GUIs
  Jedes TUI-Programm muss Scrollen selbst neu implementieren. Deshalb unterstützen TUI-Programme oft nur zeilenweises Scrollen, selbst wenn das Terminal pixelgenaues Scrollen kann, und jedes verhält sich anders. Das Scrollback in senpai funktioniert anders als in den anderen Programmen, die ich benutze, sodass ich ständig die Orientierung verliere
  Es gibt auch keine Möglichkeit, dem Terminal mitzuteilen, dass die Oberfläche mehr als nur ein einzelnes Textpanel ist, wodurch Textauswahl oft kaputtgeht. Man kann zwar Mausereignisse abfangen, aber das ist auf seine eigene Art auch unschön. In einem TUI-IRC-Client musste ich für Textauswahl per Tastenkürzel die diversen Seitenpanels ausblenden, was ein ziemlich dämlicher Ablauf war
  Die Einschränkung, sich an ein Raster halten zu müssen, begrenzt Layout- und Designmöglichkeiten stark. Ich denke dabei an diese Art von Styling, bei der etwas wie ein klickbarer Button aussehen soll, oder an Dinge wie Kontextmenüs. Ich habe mich früher schon einmal über dieses Problem beschwert
  Dass TUIs zunehmen, ist aus meiner Sicht ein bedauerliches Ergebnis des schlechten Zustands traditioneller GUI-Frameworks. TUI-Frameworks sind vergleichsweise stabil, und selbst sehr alte wirken nicht besonders störend. ncurses-Programme benutze ich heute noch häufig, aber ich kann mir kaum vorstellen, Motif-Programme zu verwenden
  GUI-Frameworks dagegen bieten nicht viele Optionen und brauchen deutlich mehr Pflege. Desktop-Umgebungen verändern sich, und die Erwartungen an GUIs steigen. Ich halte TUI-Barrierefreiheit für wirklich schlecht, bin mir da aber nicht völlig sicher. Es ändert sich auch alles ständig: Man baut etwas mit GTK2, dann ist es veraltet, aktualisiert auf GTK3 und soll dann zu GTK4 wechseln
  Zynisch betrachtet spielen bei Dingen wie Omarchy auch andere Faktoren mit hinein. Ein normales GUI wie xfce4-taskmanager ist langweilig, aber ein TUI wie btop sieht extrem hackerig aus. Die Leute mögen die Terminal-Ästhetik (siehe /r/unixporn) und scheinen bereit zu sein, Atmosphäre auf Kosten der Nutzbarkeit zu kaufen. Wenn man sieht, wie btop tatsächlich die Prozessliste ausblendet, spricht das dafür

  • Nachdem ich lange Webentwicklung gemacht hatte, wollte ich einmal native Anwendungsentwicklung ausprobieren. Ich habe mir angeschaut, wie man GNOME-Apps baut, und war ziemlich entmutigt, weil das so stark auf C++ ausgerichtet wirkte
    Ich hatte gehofft, dass die Einstiegshürde inzwischen niedriger wäre. In einer Welt, in der die meisten Entwickler:innen mit Hochsprachen ausgebildet werden, wirkt das wenig überzeugend, und die Komplexität von C++ schreckt mich wohl zusätzlich ab
  • Etwas am Rande: Ich verstehe nicht, warum so viele Chat-Clients es schaffen, dass der Formatierung beim Kopieren des Verlaufs alles entgleist. In Discord sieht das zum Beispiel so aus
    [
    20:41
    ]
    username1
    :
    message1
    [
    20:42
    ]
    username2
    :
    message2
    Der Matrix-Client Nheko lässt mich nicht einmal mehr als eine Zeile auf einmal auswählen
    IRC-Clients liefern dagegen standardmäßig eher so etwas
    20:41 <username1> message1
    20:42 <username2> message2
  • Ich mag Kommandozeilen-Interfaces, aber TUIs mag ich ebenfalls nicht besonders. Sie haben ihren Platz, sind aber praktisch eher raue, hässliche GUIs und verschwenden oft Terminalplatz
    Manchmal ergibt das Sinn, aber idealerweise sollte man sie nur für kleine, kurz benutzte Apps oder Ausnahmen wie Texteditoren einsetzen
  • Ich finde TUI etwas schwach, aber verglichen mit UI-Toolkits wie gtk ist es noch die weniger schlechte Wahl. Die TUI-Apps, die ich mag, sind gut erweiterbar, schnell und gut in die Linux-Kommandozeile integriert
    lf, tig, kakoune passen zum Beispiel gut zu Shell-Skripten, sodass man dieselben Skripte wiederverwenden und die Funktionalität in allen drei Apps erweitern kann. Da alle in alacritty laufen, kann ich auch Hyperlinks bauen, die in allen drei Apps und in der Shell insgesamt funktionieren
    Wenn ich träumen dürfte, hätte ich gern ein monochromes minimalistisches GUI-Toolkit, das Integration im Stil von Emacs oder acme erlaubt
  • Ich stimme im Großen und Ganzen zu, möchte aber anmerken, dass Tk still weiterläuft und auch heute noch nützlich ist. gitk ist ein Beispiel dafür

• Ich verstehe nicht, inwiefern TUIs „leicht zu automatisieren“ sein sollen. Sind sie nicht im Grunde einfach GUIs, die in der Konsole angezeigt werden?

  • Viele TUIs bieten beim Starten Flags, die wie eine Skriptsprache funktionieren. Außerdem ist es für LLMs einfacher und kostengünstiger, mit textbasierten Oberflächen zu interagieren als mit richtigen nativen GUIs oder JavaScript-lastigen Electron-Apps

• Dieser Artikel verpasst den Kern davon, warum TUIs „zurückgekommen“ sind. Schon die Behauptung an sich ist fragwürdig, aber dass ihre Popularität in letzter Zeit durch massenhaftes Vibe-Coding von Coding-Agenten wie Claude gestiegen ist, scheint zu stimmen
  Entwickler mögen den einfachen Weg. Eine plattformübergreifende TUI zu bauen ist leichter, als eine GUI zu bauen
  Der Grund, warum Web-Apps populär wurden, war derselbe: Mit Browser-Tools ließen sich plattformübergreifende Apps leicht bauen, und bei Electron ist es ähnlich, nur ohne die Last der Browser-Kompatibilität. Responsive UIs zu bauen, UIs plattformübergreifend zu rendern und Benutzereingaben zu verarbeiten, insbesondere unter Berücksichtigung von Barrierefreiheit, ist alles schwierig. Deshalb springen Entwickler sofort auf alles an, was ihnen das leichter macht
  In letzter Zeit gab es außerdem Veränderungen, die das Bauen von TUIs erleichtert haben. Die plattformübergreifende Unterstützung fortgeschrittener Funktionen ist besser geworden, es sind bekannte Bibliotheken entstanden, die komplexe Details abstrahieren, und all das scheint zur jüngsten TUI-Renaissance beigetragen zu haben
  Die übrigen Punkte des Artikels erscheinen mir etwas fragwürdig. Der Autor nennt zum Beispiel Konsistenz als Schwäche von Electron-Apps, aber auch populäre TUIs haben abgesehen von Konventionen kaum Konsistenz. Coding-Agenten haben ähnliche Tastenkürzel übernommen, aber meist nur, weil sie dieselbe Quelle kopiert haben, nämlich Claude. Diese Tastenkürzel lassen sich außerhalb von Coding-Agenten nicht gut übertragen, und die meisten TUIs, die ich benutze, unterscheiden sich bei Shortcuts und visueller Sprache ziemlich stark

  • Ich weiß nicht genau, was mit „Responsive UIs zu bauen ist schwierig“ gemeint ist. Das klingt nach Web-Themen. Einige Ideen aus dem Web mögen hier relevant sein, aber für native GUIs wirkt das etwas am Thema vorbei. Meintest du einfach „gute UIs zu bauen“ oder „UI-Toolkits zu bauen“?
    Auch „UIs plattformübergreifend zu rendern ist schwierig“ erscheint mir fragwürdig. Man braucht zwar eine Kompatibilitätsschicht und pro Plattform eine Implementierung, aber es wirkt nicht viel schwieriger als Unterstützung für nur eine Plattform. Anders wäre es natürlich, wenn sich die Zielplattformen bei der Darstellung so stark unterscheiden, dass ein gemeinsames API schwer zu entwerfen ist, aber auf der Ebene, auf der man nur Pixel auf den Bildschirm bringt, sollte das nicht so sein. Dinge wie Skalierung muss man natürlich behandeln, aber darüber hinaus sollte es ziemlich geradlinig sein, und sonst gibt es immer noch SDL
    Vermutlich ging es eher darum, dass die UI auf allen Plattformen „nativ“ aussehen soll. Dafür müsste man womöglich die jeweils bevorzugten nativen GUI-Toolkits jeder Plattform verwenden, und die unterscheiden sich nicht nur stark voneinander, sondern können auch viel größer und instabiler sein als Low-Level-Rendering-APIs. Dafür ist das Leben zu kurz. Ich würde vielleicht etwas Spielraum für Farbthemen oder grafische Stilelemente lassen, aber als Einstellungen auf App-Ebene. Ich möchte meine Zeit nicht damit verschwenden, Grafiksettings der einzelnen Betriebssysteme auszulesen
    Auch die Aussage „Benutzereingaben zu verarbeiten, besonders Barrierefreiheit, ist schwierig“ wirkt seltsam. Auf Tastatur- und Mausereignisse zu hören ist trivial. Für Barrierefreiheit braucht man ordentliche Tastaturnavigation, was auch für die allgemeine Nutzbarkeit wichtig ist, sowie Unterstützung für Standard- und benutzerdefinierte Shortcuts, aber insgesamt erscheint mir das deutlich einfacher als der Rest
    Screenreader-Unterstützung kann je nach API der jeweiligen Plattform und den Unterschieden zwischen den Plattformen schwierig sein, aber das ist eher ein Rendering- als ein Eingabeproblem

• TUIs sind weniger ein „Comeback“ als vielmehr ein Zeichen dafür, dass wir das Wissen über native GUI-Programmierung verloren haben und nun mit den vorhandenen Werkzeugen das Beste daraus machen. Das ist das Ergebnis mangelnder kontinuierlicher Entwicklung und Investition
  Abgesehen von ein paar hellen Ausnahmen wie Qt ist die UI-Zivilisation zusammengebrochen und wir leben gefühlt in der Zeit danach
  Es fühlt sich an, als würde das auf den Vortrag Preventing the Collapse of Civilization reimen, und jetzt, wo KI einen großen Teil des Codes schreibt, mache ich mir Sorgen, dass sich dieser Wissensverfall noch weiter ausbreitet

  • Jedes Mal, wenn dieses Thema auf lobste.rs auftaucht, mische ich mich ein, also wohl auch hier. Sämtliche GUI-„Imperien“ zerfallen vor unseren Augen: Windows, macOS, GTK, Mozilla-Produkte, alle
    Es fühlt sich an, als bräuchten wir ein After Virtue für die Informatik, und vielleicht erfüllt Blows Online-Präsenz diese Rolle bereits ein wenig. Jedenfalls vermisse ich die Zeit der Computeroberflächen, die Konsistenz zeigten, Nutzer respektierten und Lernen sowie Sorgfalt belohnten

• Dieser Artikel hat inhaltlich nicht viel Substanz und sagt im Grunde nur, dass der Autor alles andere miserabel findet
  Eine Sache will ich aber sagen: Emacs ist eine großartige Plattform für text-, tastatur-, button- und rich-media-basierte Oberflächen

• Vermutlich liegt es daran, dass Leute in Go, Rust und inzwischen Zig TUI-Bibliotheken statt ncurses verwenden. Damit sind immerhin die schrecklichen Portabilitätsprobleme gelöst, für die man früher ncurses brauchte
  Danach haben die Leute begonnen, neue Terminals zu bauen und auch die Technik auf dieser Seite weiter voranzutreiben. Teilweise, weil man das jetzt eben in Go, Rust oder Zig statt in C tun kann
  Wenn man den Leuten gute Alternativen gibt, die mehr Spaß machen und weniger nervig sind als C und C++, dann schreiben sie natürlich mehr neuen und nützlichen Code

• Der wahre Grund für die Rückkehr von TUIs ist, dass man 2026 für die Verteilung einer signierten und notariell beglaubigten GUI Apple bezahlen muss und unter Windows auch noch einer Zertifizierungsstelle Geld geben darf

  • Gilt dasselbe Problem nicht auch für native TUI-Binärdateien?

• Kleine Korrektur im Detail: Zeds GPU-beschleunigte UI-Bibliothek ist nicht die plattformübergreifende API wgpu, sondern gpui

• Ich weiß nicht, ob der Artikel seine These wirklich belegt, aber als jemand, der die MS-DOS-Zeit erlebt hat und TUIs immer mochte, werfe ich auch mal etwas ein. Wer afl-fuzz benutzt hat, wird das vielleicht nachvollziehen können
  Theoretisch hätten TUIs unter Linux viel erfolgreicher sein müssen. Es gab ein technisches Publikum mit einer Vorliebe für textbasierte Ästhetik und dazu noch den „Vorteil“ einer groben, inkonsistenten GUI-Umgebung. Es gab Zeiten, in denen schon das korrekte Funktionieren einer Grafikkarte mit dem X-Server ein Problem war
  Gleichzeitig hatten *nix-Softwareentwickler über Jahrzehnte hinweg das Gefühl, sogar alte und exotische Terminaltypen unterstützen zu müssen. Als wäre es eine Katastrophe, wenn eine Anwendung nicht korrekt auf einem DECwriter gerendert wird, und unter solchen Einschränkungen war es schwer, gute TUIs zu bauen
  In der MS-DOS-Ära hatten Unternehmen wie Microsoft, Borland und Norton funktionale und reaktionsschnelle textbasierte Oberflächen perfektioniert. Unter Linux war der „Höhepunkt“ des TUI-Designs lange Zeit das Monstrum menuconfig, und wenn man die Augen genug zusammenkneift, kann man sogar vim als TUI bezeichnen. Von den guten Linux-TUIs aus der Zeit, in der die Leute tatsächlich Textmodus-Konsolen benutzten, fällt mir im Wesentlichen nur der von Norton Commander inspirierte Dateimanager Midnight Commander ein