Der Aufbau von Terminal-UIs ist jetzt einfach geworden

 (hatchet.run)
22 Punkte von GN⁺ 2026-02-15 | 1 Kommentare | Auf WhatsApp teilen
  • Der Hatchet-Teams stellt einen Fall vor, in dem es mit Claude Code schnell eine terminalbasierte UI (TUI) entwickelt hat
  • Mit dem Charm-Stack (Bubble Tea, Lip Gloss, Huh) wurden komponentenbasierte Entwicklung auf React-Niveau und konsistentes Styling umgesetzt
  • Trotz derselben API wie in der bestehenden Web-UI steigert eine textzentrierte, informationsdichte Oberfläche die Effizienz für Entwickler
  • Claude Code startet tmux-Sitzungen und automatisiert Tests, was bei iterativer Entwicklung und der Absicherung der Stabilität eine große Rolle spielt
  • Die in nur zwei Tagen fertiggestellte Hatchet-TUI wird als Beispiel dafür bewertet, dass LLM-basierte Entwicklung die Produktivität praktisch steigert

Motivation für die TUI-Entwicklung

  • Das Hatchet-Team wollte eine TUI ähnlich k9s; Nutzer bewerteten sie als schneller und intuitiver als eine Web-UI
    • In Nutzerfeedback hieß es unter anderem: „CLI und TUI sind deutlich performanter“
  • Eine TUI ermöglicht es, Workflows in derselben Umgebung wie der Code zu visualisieren und auszuführen, sodass kein Wechsel zwischen Tabs nötig ist
  • Da die wichtigsten Hatchet-Nutzer Entwickler sind, die innerhalb ihrer IDE arbeiten, war das Ziel, ein Workflow-Management-Erlebnis direkt im Terminal bereitzustellen

Technologie-Stack

  • Verwendet wurde der Charm-Stack als Gegenstück zu einem typischen Frontend-Stack (React, Tailwind usw.)
    • Wichtige Bibliotheken: Bubble Tea, Lip Gloss, Huh
    • Sie werden vom Charm-Team gepflegt und bieten umfangreiche Dokumentation und viele Beispiele
  • Mit Lip Gloss und Huh-Themes wurde über die gesamte TUI hinweg ein konsistenter Stil angewendet
    • Dasselbe Theme wurde auch für Hatchet-CLI-Befehle wiederverwendet, um eine einheitliche User Experience zu bieten
  • Eigene Anpassungen außerhalb von Bubble Tea sind etwas schwieriger, aber deutlich einfacher, als selbst eine React-basierte Rendering-Engine zu bauen

Testansatz

  • Claude Code führt terminalbasierte Tools direkt aus und übernimmt die Tests
    • Mit tmux capture-pane werden gerenderte Ansichten erfasst und auf korrekte Ausgabe geprüft
  • Dieser Ansatz war sehr effektiv für die Automatisierung des ersten Testdurchlaufs; auch bei einer wachsenden Zahl von Views ließ sich das Rendering stabil überprüfen
  • Danach wurden manuelle Tests und Unit-Tests kombiniert, um eine stabile iterative Entwicklungsschleife zu schaffen
  • Claude Code ist für wiederholte Aufgaben in einer ASCII-Umgebung optimiert, wodurch sich die Test-Feedback-Schleife schnell einpendelt

Aufbau einer effizienten Entwicklungsumgebung

  • Claude Code erhöhte die Entwicklungseffizienz, indem es die bestehende Hatchet-Frontend-Implementierung als Referenz nutzte
    • Die einfache, React-basierte Komponentenstruktur und die OpenAPI-Spezifikation halfen dabei, klare Grenzen zu definieren
    • Über den automatisch generierten REST-API-Client war spezifikationsbasierte Entwicklung möglich
  • Die Implementierung eines DAG-basierten Renderers war der schwierigste Teil,
    • mit Verweis auf mermaid-ascii wurde jedoch erfolgreich ein ASCII-Graph-Renderer umgesetzt
    • Nicht perfekt, aber mit einer funktionsfähigen DAG-Visualisierung

Ergebnisse und Erkenntnisse

  • Die gesamte Entwicklungszeit betrug etwa zwei Tage und war damit deutlich schneller und stabiler als ein früheres Frontend-Refactoring
  • Die Entwicklung mit Claude Code wird als erster Fall bewertet, der eine nicht zufällige und praktische Produktivitätssteigerung gezeigt hat
  • Das Hatchet-Team plant, LLM-basierte Entwicklung künftig schrittweise auch auf nicht zum Kernpfad gehörende Funktionen auszuweiten
  • Die wichtigste Lehre ist die Bedeutung von kurzen Feedback-Schleifen, Modularisierung, spezifikationsbasierter Gestaltung und kontinuierlichem Testen
  • Die fertige Hatchet-TUI ist unter https://tui.hatchet.run verfügbar; derzeit wird Nutzerfeedback gesammelt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-15
Hacker-News-Kommentare

  • Es ist schon ironisch, dass eine Webseite über Terminal-UI-Performance spricht, aber auf meinem leistungsstarken Dell-XPS-Laptop selbst durch aufwendige Effekte wie CSS-Maskenkomposition oder kubische Farbverläufe ruckelig scrollt.
    Laut Gemini handelt es sich dabei um ein „Scrim oder Easing Gradient“, das statt eines sanften Fade-outs mit 16 Farbstopps bei jedem Scrollen die Farbwerte für Millionen von Pixeln neu berechnet.
    In Firefox scrollen die meisten Seiten flüssig, daher würde ich empfehlen, auch auf hiDPI-Laptops mit iGPU und nicht nur auf Macs zu testen.
    Zur Referenz gibt es auch ein Bild mit deaktiviertem Farbverlauf — Link

    • Stimmt. Ich werde mir zuerst ansehen, wie wir den Effekt entfernen und die Performance verbessern oder ihn ganz weglassen können. Danke für das Feedback.
    • „Auf Commodore-64-Niveau“ ist schon hart. Der C64 konnte tatsächlich flüssig scrollen.
    • Hier wird erklärt, wie man es in Firefox oder anderen Browsern ohne CSS oder JS lesen kann. Vorgestellt wird ein einfaches Skript, das mit busybox ssl_client und grep HTML extrahiert und dann in Firefox öffnet.
    • Es fiel auf, wie oft Claude Code in dem Blogpost erwähnt wurde.
    • Lasst bitte meinen Commodore 64 aus dem Spiel. Wenn ein Programm einmal geladen ist, läuft es mit sehr flüssigen 50–60 Hz.

  • Ich finde Versuche, TUIs wie GUIs aussehen zu lassen, irgendwie traurig. Die Zugänglichkeit leidet, die Struktur wird flach, und Nutzer können sie nur auf die vorgesehene Weise verwenden. Moderne GUIs sind dagegen strukturell mit dem OS verbunden und dadurch viel freier.

    • Sehe ich nicht so. In manchen Problemfeldern ist eine TUI viel besser geeignet. Debian-Paketkonfigurationsdialoge sind zum Beispiel deutlich angenehmer als reiner Text und funktionieren auch gut über SSH oder eine serielle Konsole. Auch bei Tools, die visuelle Informationen wie CPU-Graphen zeigen, ist das nützlich.
    • Ich nutze TUIs gern, weil ich nicht noch eine Electron-App installieren muss. Sie sind leichtgewichtig und verschwenden weniger Ressourcen, weil sie keinen Browser einbetten.
    • Ich habe das Gefühl, dass die Einschränkungen einer TUI die Konzentration von UI-Designern eher fördern. Heutige Apps verstecken ständig Menüs, TUI ist klarer.
    • Ich mag es, wenn alles im Terminal läuft. Mein Workflow dreht sich um Multiplexer wie tmux, und sobald ein separates Fenster aufgeht, ist mein Flow unterbrochen. Die Einschränkungen sorgen eher für Einfachheit und Konsistenz.
    • Wenn man sich Beispiele wie Emacs, Vim, mc, htop oder mutt ansieht, ist TUI mehr als leistungsfähig genug. Nicht jede UI muss verspielt oder offen sein.

  • TUI-Entwicklung ist viel einfacher geworden als früher. Das liegt an Frameworks wie BubbleTea, Textualize und Ratatui.
    Dank LLMs lassen sich solche Tools schnell bauen, und ich pflege eine TUI-Chart-Bibliothek namens NTCharts.
    Mit Geminis räumlichem Verständnis konnte ich Bugs beheben, und aktuell baue ich mit BubbleTea einen lokalen LLM-Chat-Viewer.
    Relevante Links: NTCharts-Issue, thinkt-Projekt

  • Ich verstehe die TUI-Besessenheit bei LLM-Apps nicht. Wenn man sich Copilot in VS2026 ansieht, zeigt eine GUI viel mehr Informationen viel schneller. Man kann Diffs in Echtzeit anklicken und prüfen, was deutlich effizienter ist.

    • Ich nutze VSCode, und seit man die AI-Agent-Sidebar in ein separates Fenster auslagern kann, ist das viel bequemer als Claude Code. Die visuelle Informationsdichte und Präzision sind bei einer TUI deutlich höher.
    • Der Grund ist Einfachheit. Eine TUI ist der einfachste Weg, schnell eine UI über ein Dateisystem zu legen. Mit Web-Technologien braucht man dafür Browser und Server.
    • Die Funktionen von Claude Code sind gut, aber die AI-Diff-Vorschau-UI in VSCode ist meiner Meinung nach deutlich besser. Die neue integrierte Version hat allerdings noch viele Bugs.
    • Eigentlich ist das eine Art LARP (Rollenspiel). Es ist nur eine symbolische Geste, um wie ein „echter Hacker“ zu wirken, während es in Wirklichkeit eine mit React/CSS gebaute Web-App ist.

  • In einer Zeit, in der LLMs Rechenressourcen verschlingen, ist das eher ein Anlass geworden, wieder Tools mit leichtgewichtigem Stack zu bauen.
    Ich habe etwas in C geschrieben, damit die CPU-Leistung um ein Tausendfaches steigt und der RAM-Verbrauch halbiert wird. TUI ist ein gutes Beispiel für diese Effizienz.

    • Trotzdem könnten native GUIs oder Frameworks wie Flutter performanter sein als TUI.
    • Ich frage mich, wie viel der für das LLM-Training eingesetzten Energie durch Optimierung überhaupt kompensiert werden kann.
    • TUI hilft auch dabei, Abhängigkeiten zu reduzieren. Früher brauchte man 100 npm-Pakete, heute reichen 200 Zeilen JS.

  • Midnight Commander (mc) ist meiner Meinung nach immer noch eine der besten TUIs überhaupt. Er bietet fast dieselben Funktionen wie die GUI-Version Double Commander und lässt sich auch remote ausführen.
    Ich arbeite gerade an einem neuen Skin und hoffe, dass er in die nächste Version aufgenommen wird.

    • Persönlich finde ich Far Manager oder Dos Navigator stabiler.
    • Danke an die mc-Entwickler.

  • Gemini hat eine TUI für mein DHT-Scraper-Projekt gebaut — Bild
    Die erste Version musste wegen Problemen mit CJK-Zeichen überarbeitet werden, aber insgesamt war ich beeindruckt. Dadurch konnte ich mich auf den Algorithmus konzentrieren.

    • Ich würde gern wissen, welche Bibliothek dafür verwendet wurde.
    • Ich interessiere mich für DHT-bezogene Projekte. Mich würde interessieren, wie das etwa bei Suchmaschinen genutzt wird.
    • Es wird nachgefragt, ob „DHT“ für Distributed Hash Table steht. Die TUI wird als cool bewertet.

  • Ich sehe nicht so recht, was TUI besser macht als Web-Formulare oder GUIs. Dagegen halte ich die Kombination von CLI-Pipelines für sehr mächtig.

    • Einige Behörden (NSA, CSE, GCHQ usw.) verbieten aus Sicherheitsgründen Web-Admin-UIs. Deshalb wird unser Produkt über lokale Konsole oder SSH-basierte TUI verwaltet. Wir nutzen sehr restriktive SELinux-MAC-Einstellungen.
    • Für Apps, die neben der CLI laufen sollen, ist TUI praktisch. Mit tmux/zellij lassen sich Fenster leicht aufteilen, und es gibt weniger UI-Unterschiede zwischen Betriebssystemen.
    • TUI ist besonders in SSH-Umgebungen nützlich. Sie funktioniert sogar gut in SSH-Clients auf Smartphones.
    • Gemini hat eine TUI für mein C#-Projekt gebaut, später aber vorgeschlagen, dass ein eingebetteter Kestrel-Webserver besser wäre. Das stimmte.
    • TUI bietet gute Keybindings und ist direkt dort verfügbar, wo Befehle ausgeführt werden, was sie für schnelle Aufgaben geeignet macht.

  • Ich mag Claude Code, aber die React-basierte TUI-Architektur wirkt wirklich ineffizient.

    • Besonders beim Scrollen durch lange Texte gibt es starke Performance-Einbrüche. Es scheint so, als wäre die Architektur von Anfang an so gewesen, und ich frage mich, warum sie so schwer zu beheben ist.
    • Wenn das Rendering ohnehin schon in JS passiert, könnte es sinnvoll sein, React als Recycling-Engine zu verwenden.

  • Ich habe auf Basis von Cursor CLI mein eigenes Prompt-Frontend gebaut — Bild
    Ich habe git, diff und Chat-Historie integriert, und über Tailscale ist es auch vom Handy aus leicht erreichbar.
    Es erkennt meine Regeln und kann im Projekt mit grep suchen, was die Nutzbarkeit stark erhöht.