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⁺]

Hacker-News-Kommentare

• Wenn man nur auf die Zahlen schaut, ist der eigentliche Grund für die Beliebtheit von TUIs Claude Code; alles andere ist im Vergleich dazu fast nur Hintergrundrauschen.
  Ich wollte ursprünglich wegen der Idee ein TUI bauen, Apps über SSH auszuliefern. SSH-Apps ähneln dem Browser insofern, als keine lokale Installation nötig ist.
  Ein großer Grund, warum ich so gern mit https://pico.sh herumspiele, ist auch, dass die Bereitstellung von TUIs keinerlei Eingriff durch den Nutzer erfordert.

  • Ich glaube nicht, dass das stimmt. Der Zeitpunkt, an dem neue TUI-Programme zunahmen, scheint vor dem eigentlichen Durchbruch von Claude Code zu liegen.
  • Claude Code hat den Trend zwar sicher um das Hundertfache verstärkt, aber schon in den Zeiten von go fzf, Rust ratatui und Python Rich gab es einen starken Zuwachs bei TUIs.
    Der Grund dürfte der Wunsch sein, schweren browserbasierten UIs zu entkommen, zusammen mit der Neugier, die Grenzen des Terminal-Renderings auszureizen.
  • Ich verstehe die Idee, Apps über SSH auszuliefern, aber es ist trotzdem schade, dass der Schreibmaschinen-Emulator für serielle Ports bis hierhin überlebt hat.
    Statt mit neuer und spannender Technik neue Systeme zu bauen, machen wir GPU-beschleunigte Schreibmaschinen-Emulatoren. Das ist eine seltsame Mischung aus Nostalgie und technischer Blindheit.
    Über SSH kann man jedes beliebige Protokoll tunneln. Lieber würde ich sehen, dass wir uns in Richtung Zeichnen auf einem entfernten Bitmap-Display bewegen.
    X Window war nicht perfekt entworfen, hatte aber Netzwerktransparenz, und devdraw von Plan 9 war eine Rendering-Engine, bei der entfernte Grafikprogramme Assets hochluden und dann Linienzeichenbefehle per RPC schickten.
  • Der Grund, warum man statt einer reinen CLI oder GUI zu einer TUI-App greifen möchte, ist für mich immer noch die Nutzbarkeit über SSH.
  • Ich frage mich, ob mit der Beliebtheit von TUIs gemeint ist, dass alle Claude Code nachahmen wollen, oder ob es heißt, dass TUI-Entwicklung dank Claude Code einfacher geworden ist.

• Das einzig wirklich Schwierige an vim ist, dass man für die Rückkehr in den Befehlsmodus, also den Kern eines modalen Editors, die Finger bis zur Escape-Taste strecken muss.
  Der ideale Ablauf ist schnelles Editieren und sofort zurück in den Befehlsmodus, und die Verwendung von Escape ist ein historisches Überbleibsel, das man benennen sollte.
  Deshalb sollte man CapsLock global auf Escape umbelegen. Unter Linux und macOS geht das allein über die GUI-Einstellungen, und unter Windows ist es mit einem Registry-Eintrag in einer Minute erledigt.
  Davon abgesehen kann man die Grundlagen mit vim-tutor lernen und alles Weitere nachschlagen, wenn man auf etwas Zeitaufwendiges stößt, daher sehe ich nicht so recht, wo die Lernkurve liegen soll. Das Problem ist eher, dass man sich zu schnell an modales Editieren gewöhnt und Umgebungen ohne es sich wie die Steinzeit anfühlen.

  • Wenn man regelmäßig zwischen mehreren Laptops wechselt, ist CapsLock auf Escape umzubelegen durchaus eine spürbare Reibung. Das Muskelgedächtnis kommt ständig dazwischen.
  • Ich habe noch niemanden gesehen, der CapsLock auf Escape umgestellt hat und dann wieder zurückgegangen ist. Der Unterschied im Gefühl ist enorm.
    Inzwischen denke ich, dass vim hjkl eigentlich nur deshalb braucht, weil Tastaturlayouts für Pfeiltasten schlecht sind. Schreibmaschinen hatten keine Pfeiltasten, aber auf Computern sind sie zentral.
    Die Leertaste müsste gar nicht so groß sein und auch nicht von beiden Daumen benutzt werden. Es wäre viel besser, einen kleinen Pfeiltastenblock links oder rechts in einen Teil des Bereichs der Leertaste zu verlegen.
    Der hjkl-Hack funktioniert nur in Editoren für Hacker, aber auch in normaler Software braucht man oft Pfeiltasten, und das heutige Layout ist sehr schlecht für die Hände. Bei mir fing es schon an, sich zu entzünden, weil ich versuchte, die Pfeiltasten mit dem Daumen zu drücken, ohne die ganze Hand zu bewegen.
  • Seltsamerweise gefällt mir die weit entfernte Esc-Taste nicht aus Effizienzgründen, sondern aus ergonomischen.
    Man hebt die Hand aus der Home-Position und setzt sie wieder zurück, was RSI-Punkte reduziert, die sich sonst still ansammeln würden.
    Aus demselben Grund nutze ich mit der anderen Hand auch oft die Pfeiltasten. Natürlich verwende ich hjkl ebenfalls ziemlich oft.
  • Unter Windows enthält PowerToys ein ziemlich gutes Tool zum Umbelegen der Tastatur.
    https://github.com/microsoft/PowerToys
  • Die Finger sind ohnehin schon auf der Home-Position, also mappt man es einfach auf jj.
    Außerdem ist Ctrl + [ in Standard-Terminal/ASCII Esc, was bequemer sein kann, als bis zur Esc-Taste zu greifen.

• Was wie ein TUI-Trend aussieht, ist die Asche der zusammengebrochenen Eigeninteressen der Betriebssystemanbieter.
  Es gibt keine einzige gute allgemeine UI. Der Browser ist noch das Beste und recht erfolgreich, aber wegen der Sandbox ist er für Dinge, die lokalen Datei- oder Netzwerkzugriff brauchen, ungeeignet oder mit Reibung verbunden. Selbst um etwas Einfaches auszuführen, ist der Overhead absurd hoch.
  Fernzugriff ist noch schlimmer. Dann tauchen Fragen auf wie: Kann ich von einem Mac auf eine App zugreifen, die auf einem Windows-Host läuft? Lässt sich das über einen Tunnel weiterleiten?
  TUI ist ein einfaches allgemeines Protokoll, das tut, was man braucht, und Remote-Nutzung ist eingebaut. Was lokal funktioniert, läuft auch über eine SSH-Verbindung ganz natürlich.
  Es ist auch ein riesiger Mittelfinger an OS-Anbieter, die glaubten, es sei die Gewinnerstrategie, alles inkompatibel zu machen oder die Leute im eigenen Ökosystem festzuhalten.

  • TUIs sind für Nutzer leicht zu verstehen, effizient sowohl bei Ressourcen als auch bei der Bedienung, und in guten Terminals sehen sie auch gut aus.
    Notcurses und Ratatui haben ncurses sehr geholfen.
  • Weil die absurden modernen GUI-Umgebungen versagt haben, lande ich immer wieder bei minimalistischen Desktop-Umgebungen wie xfce4.
    Windows 11 ist ein sehr gutes Beispiel; all dieser Ballast ist wirklich nicht nötig.

• Ich wünschte, TUI käme nicht zurück. Ich würde an jedem Tag der Woche ein Web-Interface einer TUI vorziehen.
  Man muss keine übertrieben cleveren Fonts installieren, nicht an Terminal-Einstellungen herumdrehen, damit alles korrekt dargestellt wird, und nicht erraten, welche Navigationskürzel der Autor für die besten hält.
  Dazu kommen echte Textbearbeitung mit Standard-Textnavigation des Betriebssystems sowie bessere Integration mit Passwortmanagern, Texterweiterern usw.
  Ich lebe in der CLI und öffne das Terminal mit einem einzigen Shortcut, aber seit der Zeit, in der das Terminal die einzige Wahl war, hat sich die Technik stark weiterentwickelt, und es gibt bessere Optionen, um UIs zu bauen.

  • Web-Interfaces sind auch nicht besser. Sie werden zugunsten der Ästhetik statt der Funktion entworfen, und jedes bringt seine eigenen UI-Konventionen mit, die man lernen muss.
  • Ich habe jahrzehntelang vim und Emacs benutzt, bin aber vor ein paar Jahren auf GUIs umgestiegen und habe keinerlei Wunsch, zurückzugehen.
    Dieser ganze TUI-Trend wirkt auf mich einfach wie eine Modeerscheinung.

• Weil niemand in native UI-Entwicklung investiert. Electron ist der Beweis, dass Unternehmen einen leicht nutzbaren GUI-Stack übernehmen würden, wenn es ihn gäbe.

  • Im Artikel heißt es, Google habe vor einem echten Produktlaunch aufgegeben, aber ich würde sagen, dass die Arbeit an Flutter weitergeht und die Nutzung zunimmt.
  • Am schlimmsten ist es bei kleinen Utilities, zum Beispiel einem Tool zum Durchsuchen von Dateien per Regex.
    Bei großen Apps machen Paketierung und Auslieferung einen kleineren Teil des Ganzen aus, und die Dateigröße ist weniger wichtig, aber bei kleinen Apps ist das anders.
    Apps für Windows sind einfach: eine kleine Binärdatei öffnet ein Formular, läuft per Doppelklick und braucht keine Installation.
    Unter Linux kann man dasselbe nicht ohne Weiteres tun, weil nicht garantiert ist, dass GTK oder Qt installiert sind; wenn man es standalone machen will, muss man praktisch das ganze Betriebssystem mitschicken. Dadurch werden die Dateien groß.
    Auch Python ist schwierig, weil Windows-Nutzer entweder Python installiert haben müssen oder man den Interpreter mitschicken muss.
    Die einzig halbwegs brauchbare Alternative ist etwas wie Java mit einer einzelnen .jar-Datei, die auf jedem System läuft, aber Oracle hat die Lizenz geändert, und JavaFX ist nicht mehr Teil von Java. Swing ist noch enthalten.
    Ich will doch nur eine Menüleiste mit Tastaturkürzeln anzeigen; warum gibt es nicht so etwas wie eine Menüleisten-VM, die einem auf jedem Betriebssystem Zugriff auf die Menüleiste gibt?
    Mit Electron gleich einen ganzen Browser mitzuliefern ist albern. Es sollte eher so sein, dass Nutzer eine Plattform wie die Desktop-App-Version von Flash installieren und dann alle Apps diese nutzen.
    Vielleicht ist es leichter, DOS-Spiele zu verteilen als Desktop-Apps. Wer DOS-Spiele spielen will, hat wahrscheinlich ohnehin schon einen DOS-Emulator installiert.
  • Weniger fehlende Investition, eher weil nichts Vernünftiges gebaut wurde.
    Was gebraucht wird, ist ein Framework, das leicht zu benutzen, plattformübergreifend, Open Source und möglichst in der gewählten Programmiersprache nutzbar ist.
  • Zed hat das tatsächlich getan. Es hat Fans, aber gemessen an dem enormen Aufwand, ein GUI-System von Grund auf neu zu bauen, scheint die Verbreitung nicht gerade explosionsartig zu steigen.
  • Sind wxWidgets und Qt nicht ganz okay? GTK 2 und 3 auch, nur 4 und höher eher nicht. Es gibt viele Apps, die eines davon nutzen, oft auch über Python-Bindings.
    Das größere Problem ist die Personalfrage. Es gibt viele Leute, die Webentwicklung können, also will man diese Leute auch für Desktop einsetzen, und wenn Desktop mit Electron einfach JavaScript ist, wird das deutlich leichter.

• Ich verstehe nicht so recht, warum Terminal-UIs GUI-ähnliche Funktionen neu bauen wollen. Sollten Computeroberflächen nicht besser werden statt schlechter?
  Wir müssen nicht mehr auf Zeichenraster beschränkt sein, nur um so zu tun, als würden wir Linien und Formen zeichnen. Ohne nicht standardisierte Terminals wie Kitty oder iTerm kann man nicht einmal Bilder anzeigen.
  Schade, dass es kein hervorragendes plattformübergreifendes Streaming-UI-System gibt. Das Web ist in gewisser Weise großartig, aber für diesen Zweck müsste es doch klar etwas Besseres geben. Flutter ist okay, aber nicht On-Demand genug und zu stark an Dart gebunden.

  • Das liegt am Versagen moderner GUI-Umgebungen.
    Die Leute wollen GUIs, müssen dann aber auf etwas GUI-ähnliches innerhalb von TUIs ausweichen.
    Sie wollen etwas Portables, remote Ausführbares, etwas, das sicherer laufen kann, ohne Sockets offenzulegen, und ohne einen kompletten Desktop starten zu müssen.
    Rootlose Fenster sind praktisch tot; übrig bleiben Web-Interfaces mit all ihren Problemen oder TUI über eine SSH-Verbindung, die ohnehin jeder schon hat.
    Früher konnte man mit Tcl/Tk schnell etwas zusammenbauen und ein Fenster über X Window öffnen, aber heute ist das nicht mehr einfach, und Remote-X benutzt niemand mehr.
    SSH ist der kleinste gemeinsame Nenner, und nur Dinge, die dazu passen, überleben.
  • Was Bildanzeige angeht: Sixel wird von vielen Terminals unterstützt[0].
    Mehrere der als nicht unterstützt genannten Terminals basieren ebenfalls auf GNOME VTE, dort ist die Unterstützung in Arbeit, und wenn man in den Bugtrackern schaut, scheint es fast fertig zu sein.
    Dazu gehört auch xterm, das unter X11 wohl am ehesten dem Standard-Terminal entspricht.
    [0] https://www.arewesixelyet.com/
  • TUI ist beliebt, weil man damit Dinge leicht fertigbekommt. Baut man eine ordentliche GUI, wird die Codebasis plötzlich viel komplexer.
    Es gibt kein solides, verlässliches GUI-Toolkit; alle sind mit unterschiedlichen Bugs und Fallstricken beladen.
    Flutter mag okay sein, aber dafür muss man ausblenden, dass allein der Build-Prozess für eine Flutter-App ein Albtraum ist. Auch Flutter selbst wirkt nicht so, als sei es dafür gedacht, von jedem kompiliert zu werden; in der Praxis kaschieren Distributionen dieses Problem nur.
  • Ein plattformübergreifendes Streaming-UI-System könnte man auch einfach Web/Jupyter nennen.
    Und webbasierte UIs müssen nicht zwingend schwergewichtig sein. Hacker News ist es schließlich auch nicht.
  • Über SSH ist Text einfach schneller. Grafisches Neuzeichnen wie bei RDP oder VNC ist auf Dauer langsamer und umständlicher.

• Obwohl ich immer ein Terminal offen habe, mein Leben mit Bash-Skripten automatisiere und VIM/TMUX nutze, liegen die meisten TUIs zwei Schritte hinter einer guten GUI zurück.
  Beliebige Navigation und Shortcuts, kaputtes Copy-and-Paste und mangelnde Integration in die Umgebung sind typische Beispiele.
  Das Kernproblem ist, dass es keine vernünftige plattformübergreifende GUI-Plattform gibt, die sauber in Programmiersprachen integriert ist oder Teil der Standardbibliothek wäre.
  Swing fehlt der Zugriff auf native Browser-Elemente, Tk fehlen Browser-Komponenten und Drag-and-Drop, wxWidgets hat eine kleine Community, und seine Bindings mussten offenbar mehr als einmal wiederbelebt werden.
  Qt könnte jederzeit zugunsten höherer Einnahmen kaputtgemacht werden, ich halte KDE nicht für so wichtig, und ich bezweifle, dass die KDE-Community langfristig einen Fork tragen könnte.
  Übrig bleiben Electron oder Mischformen, die JavaScript/CSS über Browser-Komponenten legen und lokale Server-Callbacks ankleben; abgesehen vom hohen Speicher- und Laufzeit-Overhead selbst für triviale Apps ist auch das Programmiermodell selbst schlecht.
  Um ein ordentliches plattformübergreifendes GUI-Toolkit zu bauen, braucht es viel Geld und viele Leute für Usability, Accessibility, Design, Dokumentation und Tests. Die Open-Source-Community hat das nicht geschafft, GTK ist praktisch Linux-only geworden, und es gibt keinen modernen Ersatz für Qt oder Swing.
  TUI ist keine Lösung für das Grundproblem, aber wenn man sich die Alternativen ansieht, kann ich Entwickler verstehen, die TUI für plattformübergreifende UIs wählen. Für etwa 80 % der GUI-Anforderungen würde vermutlich schon ein GUI-Toolkit mit TUI-Renderer reichen.

  • Es sollte nicht als Programmiersprache, sondern als C API bereitgestellt werden.
    So kann man eine stabile API und ABI anbieten und Bindings in viele andere Sprachen ohne komplizierte Umwege ermöglichen. Gerade bei kompilierten Sprachen ist das besonders wichtig.
    Qt an Python zu binden mag einfach sein, aber wenn man es an eine Sprache wie Free Pascal anbinden will, braucht man eine vermittelnde C++-Bibliothek, die ein C API exponiert, und man muss diese Bibliothek dann auch noch mit der App ausliefern.
    Leider sind die meisten GUI-Toolkits nicht in C, sondern in C++ oder anderen Sprachen geschrieben, was sie schmerzhaft in der Nutzung macht, wenn die bevorzugte Sprache des Entwicklers eine andere ist. Unter den Mainstream-Optionen ist GTK fast das einzige größere Toolkit, das in C geschrieben ist, aber GTK kümmert sich kaum um angemessene Abwärtskompatibilität.
    Man könnte sagen, die Bibliothek könne intern in jeder Sprache geschrieben sein, solange sie nur ein C API nach außen anbietet, aber wenn sie nicht breit verteilt ist, möchte man sie vielleicht statisch linken. Außerhalb von C/C++ wird das dann problematisch.
    Ich habe zum Beispiel versucht, ein FLTK-Backend für Lazarus zu bauen[0]. FLTK ist eine C++-Bibliothek und empfiehlt statisches Linken, also schien es möglich, eigenständige GUI-Binärdateien zu erzeugen.
    Aber zuerst musste ich einen C-Wrapper bauen, und unter Linux war es schmerzhaft, eine C++-Bibliothek aus einer Nicht-C/C++-Sprache statisch zu linken, wenn die magischen Flags fehlten, die g++ an den Linker übergibt. Unter Windows oder zumindest msys2 war es unmöglich, deshalb habe ich aufgegeben.
    [0] https://i.imgur.com/W6XbLkr.png
  • Stimme größtenteils zu. Gerade wxWidgets ist wirklich schade.
    Es kommt auf macOS und Windows dem nativen Look-and-Feel sehr nahe und ist viel einfacher zu programmieren als Qt. Als Nutzer und manchmal auch als Entwickler bevorzuge ich wxWidgets klar für plattformübergreifende GUIs.
    Umgekehrt hasse ich als Nutzer wirklich die Kombination aus Electron oder Browser-Komponenten mit JavaScript/CSS und lokalen Server-Callbacks. Ich würde lieber auf Funktionen verzichten und zur Kommandozeile zurückkehren, als solche Apps zu benutzen.
    Sie unterstützen keine Standard-Tastenkürzel, sehen seltsam deplatziert aus und ruckeln an unerwarteten Stellen.
    Einige TUI-Frameworks sind fast auf diesem Niveau. Dass sie sich ohne großen Aufwand über SSH und Ähnliches nutzen lassen, ist nett, aber es wirkt, als würden sie das falsche Problem lösen.
    Statt alles wie eine IDE aussehen oder funktionieren zu lassen, hätte ich lieber etwas, das stärker auf fokussierte, kombinierbare CLI setzt, zusammen mit etwas wie tmux, nur mit weniger miserabler Fensterverwaltung und Persistenz.
    Wenn man ein simples REPL mit readline baut, bekommt man standardisiertes und vorhersehbares Verhalten.
    Trotzdem gefällt mir an diesem Trend, dass er Verbesserungen bei Terminal-Emulatoren vorantreibt.

• Die TUIs, die ich mir angesehen habe, scheinen größtenteils von NPM abhängig zu sein.
  Das wirkt seltsam, als hätten die Agenten nicht einmal Zeit, sich selbst mit etwas anderem als einem Security-Reifenbrand neu zu schreiben.
  Dieser ganze Trend, dass all diese Agenten angeblich irgendetwas übernehmen, lässt mich denken, dass er von Startup-Leuten stammt, die aus Müll-zu-Müll-Startups kommen, bei denen man sich am Ende über nichts Sorgen machen muss außer darüber, dass es nicht schnell genug war.

  • 99 % der Software rund um LLMs ist weiterhin wackeliger, kaputter Web-Müll.
    OpenCode schafft zum Beispiel bis heute nicht einmal die Grundlagen, nämlich das vollständige Nachrichtenlog zu behalten und in derselben Reihenfolge an einen SSE-Endpunkt zu schicken, um die nächste Antwort zu erhalten; selbst wenn man Kontextbeschneidung abschaltet, gibt es oft Prompt-Cache-Misses.
  • Go + Lipgloss + Bubbletea ist der robusteste und performanteste Stack, um gut aussehende und brauchbare TUIs zu bauen oder generieren zu lassen.
    Die Developer Experience ist ebenfalls hervorragend, und npm ist nicht nötig.
  • Ach, die friedlichen Zeiten der Sicherheit durch curl | bash.
  • Ja. Die Leute, die begeistert überall AI einbauen, sind fast immer JavaScript/TypeScript-Entwickler, meistens in Startups, oft auch im AI-Bereich.

• Es ist schon seltsam, dass Softwareentwickler überhaupt Benutzeroberflächen entwerfen dürfen.
  Sie scheinen nicht in der Lage zu sein, Benutzeroberflächen zu bauen, die nicht textbasiert sind. Es ist, als würde man einen Klempner ein Haus entwerfen lassen, und am Ende wären alle Böden nach unten geneigt, damit sich Rohre leichter verlegen lassen.
  Wenn man mehrere Fenster verschieben und skalieren muss, bauen sie ein Textfenster; wenn man schnell Optionen auswählen muss, bauen sie ein Textfeld; und wenn man schnell ein formatiertes Dokument schreiben muss, sorgen sie dafür, dass man für die Formatierung noch mehr Text schreibt.
  Aber eine App, in der man diesen Text einfach direkt formatiert sehen kann, bauen sie dann nicht.

  • Von dürfen kann keine Rede sein; die meisten dieser Open-Source-TUI-Projekte wurden von Einzelpersonen oder kleinen Teams gestartet, die ihr eigenes Problem lösen wollten.
    Das darf man natürlich, und wenn es dir nicht gefällt, musst du es nicht benutzen.
  • Am anderen Ende des Spektrums stehen Material und in gewissem Maß Adwaita.
    Hübsch anzusehen, aber für kompliziertere Dinge als App-Styling oder vielleicht einen Dateimanager fast nutzlos.
  • Ich weiß gar nicht, wovon du sprichst. Wenn man Entwicklern ein ordentliches Design-System gibt, können sie durchaus vernünftige Dinge bauen.

• TUIs sind gut für Menschen, die im Terminal leben.
  Es gibt keine Ablenkung durch visuelle Inhalte, sie sind mit der Tastatur extrem effizient, und inzwischen kann AI sie schnell erzeugen. Früher war das wirklich schmerzhaft.

  • Dass AI sie schnell erzeugen kann, ist meiner Meinung nach der wichtigste und praktisch einzige Grund.
  • Die Folge davon ist, dass mehr Menschen daran gewöhnt sind, im Terminal zu leben.
    Das Publikum für TUIs ist gewachsen, deshalb sind TUIs auch verbreiteter geworden.
  • In TUIs gibt es keinen Platz für endloses Padding, nur um ein elegantes, modernes Erscheinungsbild zu erzeugen.
    Innerhalb von 80-Spalten-Text gibt es auch nicht viel, das ein Produktmanager noch wegvereinfachen könnte.

[savvykang]

Ist es nicht falsch, dass kein einziges Big-Tech-Unternehmen den Browser aufgibt?

[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