Créer une interface terminal est désormais devenu facile

• Le cas du développement rapide par l’équipe de Hatchet d’une interface utilisateur en terminal (TUI) à l’aide de Claude Code est présenté
• Avec la stack Charm (Bubble Tea, Lip Gloss, Huh), ils ont mis en œuvre un développement basé sur des composants au niveau de React ainsi qu’un style cohérent
• Tout en utilisant la même API que l’interface web existante, ils ont amélioré l’efficacité des développeurs grâce à une interface centrée sur le texte et riche en informations
• Claude Code lance des sessions tmux et automatise les tests, jouant ainsi un rôle majeur dans le développement itératif et la fiabilité
• Le TUI de Hatchet, achevé en seulement 2 jours, est considéré comme un exemple montrant une amélioration concrète de la productivité grâce au développement basé sur les LLM

---

Motivation pour développer un TUI

• L’équipe de Hatchet voulait un TUI similaire à k9s, et les utilisateurs l’ont jugé plus rapide et plus intuitif que l’interface web
  • Parmi les retours utilisateurs, certains indiquaient que « le CLI et le TUI sont bien plus performants »
• Un TUI permet de visualiser et exécuter les workflows dans le même environnement que le code, sans avoir à changer d’onglet
• Comme les principaux utilisateurs de Hatchet sont des développeurs travaillant dans leur IDE, l’objectif était d’offrir une expérience de gestion des workflows dans le terminal

Stack technique

• Ils ont utilisé la stack Charm, équivalent des stacks frontend classiques (React, Tailwind, etc.)
  • Bibliothèques principales : Bubble Tea, Lip Gloss, Huh
  • Elles sont maintenues par l’équipe de Charm, avec une documentation et des exemples abondants
• Lip Gloss et les thèmes Huh ont permis d’appliquer un style cohérent à l’ensemble du TUI
  • Le même thème a aussi été réutilisé dans les commandes du CLI Hatchet pour offrir une expérience utilisateur unifiée
• Les personnalisations en dehors de Bubble Tea sont un peu plus difficiles, mais cela reste bien plus simple que d’implémenter soi-même un moteur de rendu basé sur React

Approche de test

• Claude Code exécute directement les outils en terminal pour réaliser les tests
  • Il utilise tmux capture-pane pour capturer la vue rendue et vérifier que la sortie est correcte
• Cette méthode s’est révélée très efficace pour automatiser la première passe de test, avec une vérification du rendu qui reste fiable même lorsque le nombre de vues augmente
• Des tests manuels et des tests unitaires ont ensuite été menés en parallèle afin de créer une boucle de développement itérative stable
• Claude Code est particulièrement optimisé pour les tâches répétitives dans un environnement ASCII, ce qui permet une convergence rapide de la boucle de feedback de test

Mettre en place un environnement de développement efficace

• Claude Code a amélioré l’efficacité du développement en s’appuyant sur l’implémentation frontend existante de Hatchet
  • Une structure de composants simple basée sur React et la spécification OpenAPI ont permis de définir clairement les frontières
  • Un client REST API généré automatiquement a rendu possible un développement guidé par la spécification
• L’implémentation du moteur de rendu basé sur un DAG a été la partie la plus difficile, mais
  • en s’appuyant sur mermaid-ascii, ils ont réussi à implémenter un moteur de rendu de graphes ASCII
  • sans être parfait, il permet de disposer d’une fonctionnalité opérationnelle de visualisation de DAG

Résultats et enseignements

• La durée totale du développement a été d’environ 2 jours, bien plus rapide et plus stable qu’un précédent refactoring frontend
• Le développement avec Claude Code est considéré comme le premier cas montrant une amélioration réelle et non aléatoire de la productivité
• L’équipe de Hatchet prévoit à l’avenir d’étendre progressivement le développement basé sur les LLM aux fonctionnalités hors chemin critique
• La principale leçon est l’importance de boucles de feedback courtes, de la modularité, d’une conception guidée par les spécifications et de tests continus
• Le TUI finalisé de Hatchet est disponible sur https://tui.hatchet.run, et l’équipe y recueille les retours des utilisateurs

[GN⁺]

Commentaires sur Hacker News

• Il y a une certaine ironie à voir une page web parler des performances des interfaces terminal alors que le défilement saccade sur mon Dell XPS haut de gamme à cause d’effets complexes comme les masques CSS composites ou les dégradés cubiques
  D’après Gemini, il s’agit d’un « Scrim » ou d’un « Easing Gradient » : au lieu d’utiliser 16 arrêts de couleur pour produire un fondu doux, cela force à recalculer la couleur de millions de pixels à chaque scroll
  La plupart des pages défilent de façon fluide dans Firefox, donc ça vaudrait le coup de tester aussi sur des portables hiDPI à iGPU, pas seulement sur Mac
  À noter qu’il existe aussi une image avec le dégradé désactivé — lien

  • Oui, c’est vrai. Je vais déjà regarder si on peut améliorer les performances en retirant cet effet, ou le supprimer complètement. Merci pour le retour
  • Dire « au niveau d’un Commodore 64 », c’est un peu dur. Le C64 savait en réalité faire du scrolling fluide
  • Quelqu’un partage une manière de lire ça dans Firefox ou d’autres navigateurs sans CSS ni JS. Il propose un petit script qui extrait le HTML avec busybox ssl_client et grep, puis l’ouvre dans Firefox
  • J’ai été frappé par la fréquence à laquelle Claude Code est mentionné dans le billet de blog
  • Laissez mon Commodore 64 en dehors de ça. Une fois le programme chargé, ça tourne de façon très fluide à 50–60 Hz

• Je trouve un peu triste cette tentative de faire ressembler un TUI à une GUI. C’est moins accessible et la structure devient plus plate, donc l’utilisateur ne peut guère l’utiliser autrement que de la manière prévue. Les GUI modernes, au contraire, sont structurellement intégrées à l’OS et offrent bien plus de liberté

  • Je ne suis pas d’accord. Dans certains domaines, un TUI est bien plus adapté. Par exemple, les boîtes de dialogue de configuration des paquets Debian sont beaucoup plus confortables qu’un simple texte, et elles fonctionnent très bien en SSH ou sur console série. C’est aussi utile quand il faut afficher une information visuelle, comme un outil montrant des graphiques CPU
  • J’utilise les TUI parce que je n’ai pas besoin d’installer encore une application Electron. C’est léger, et sans navigateur embarqué il y a moins de gaspillage de ressources
  • J’ai l’impression que les contraintes du TUI améliorent au contraire la concentration du designer UI. Les applis récentes cachent trop souvent les menus, alors que le TUI reste clair
  • J’aime le fait que tout tourne dans le terminal. Mon workflow est centré sur des multiplexeurs comme tmux, donc dès qu’une fenêtre séparée s’ouvre, ça casse le flux. Les contraintes apportent au contraire simplicité et cohérence
  • Quand on regarde des exemples comme Emacs, Vim, mc, htop ou mutt, on voit bien qu’un TUI peut être très puissant. Toutes les interfaces n’ont pas besoin d’être ouvertes

• Le développement de TUI est devenu bien plus facile qu’avant grâce à des frameworks comme BubbleTea, Textualize et Ratatui.
  Les LLM permettent aussi de construire rapidement ce type d’outils, et je maintiens une bibliothèque de graphiques TUI appelée NTCharts
  Grâce à la compréhension spatiale de Gemini, j’ai corrigé des bugs, et je suis en train de créer avec BubbleTea un visualiseur local de conversations LLM
  Liens associés : issue NTCharts, projet thinkt

• Je ne comprends pas cette obsession du TUI dans les applications LLM. Si on regarde Copilot dans VS2026, une GUI affiche bien plus d’informations beaucoup plus vite. On peut cliquer sur les diff en temps réel, ce qui est bien plus efficace

  • J’utilise VSCode, et depuis qu’on peut détacher la barre latérale d’agent IA dans une fenêtre séparée, je trouve ça bien plus pratique que Claude Code. La densité d’information visuelle et la précision sont bien supérieures à celles d’un TUI
  • La raison est simple. Un TUI est le moyen le plus simple de poser rapidement une UI sur un système de fichiers. Avec des technologies web, il faut un navigateur et un serveur
  • Les fonctionnalités de Claude Code sont bonnes, mais je trouve l’UI d’aperçu des diff IA de VSCode bien meilleure. En revanche, la nouvelle version intégrée a encore beaucoup de bugs
  • En réalité, ça ressemble un peu à du LARP. C’est surtout un geste symbolique pour avoir l’air d’un « vrai hacker », alors qu’en pratique c’est une webapp construite en React/CSS

• À l’époque où les LLM accaparent les ressources de calcul, cela a au contraire poussé à créer des outils sur une stack légère.
  Écrire en C a permis de multiplier les performances CPU par des milliers et de réduire la RAM de moitié. Les TUI sont un bon exemple de cette efficacité

  • Malgré tout, une GUI native ou un framework comme Flutter peut parfois être plus performant qu’un TUI
  • Je me demande dans quelle mesure l’optimisation peut vraiment compenser l’énergie dépensée pour entraîner les LLM
  • Les TUI sont aussi utiles pour la réduction des dépendances. Avant il fallait 100 paquets npm, maintenant 200 lignes de JS suffisent

• Midnight Commander (mc) reste selon moi l’un des meilleurs TUI. Il offre quasiment les mêmes fonctions que sa version GUI (Double Commander), tout en pouvant tourner à distance.
  Je travaille en ce moment sur un nouveau skin, en espérant qu’il soit inclus dans la prochaine version

  • Personnellement, je trouve Far Manager ou Dos Navigator plus stables
  • Merci aux développeurs de mc

• Gemini m’a créé un TUI pour mon projet de scraper DHT — image
  La première version a nécessité des corrections à cause de problèmes avec les caractères CJK, mais dans l’ensemble c’était impressionnant. Ça m’a permis de me concentrer sur l’algorithme

  • Je me demande quelle bibliothèque a été utilisée
  • Le sujet des projets liés au DHT m’intéresse. J’aimerais savoir comment c’est utilisé, par exemple dans les moteurs de recherche
  • Vérification : « DHT » signifie bien Distributed Hash Table. Beau TUI, au passage

• Je ne vois pas très bien en quoi un TUI est meilleur qu’un formulaire web ou qu’une GUI. En revanche, je trouve les compositions de pipelines CLI extrêmement puissantes

  • Certaines organisations (NSA, CSE, GCHQ, etc.) interdisent les interfaces d’administration web pour des raisons de sécurité. Du coup, notre produit se gère via un TUI en console locale ou via SSH. On utilise une configuration SELinux MAC très restrictive
  • Un TUI est pratique pour les applications qu’on peut lancer à côté du CLI. C’est facile de découper l’écran avec tmux/zellij, et il y a moins de différences d’UI entre les OS
  • Les TUI sont particulièrement utiles en environnement SSH. Ça fonctionne aussi très bien avec des clients SSH sur smartphone
  • Gemini m’a créé un TUI pour mon projet C#, mais a ensuite suggéré qu’un serveur web Kestrel embarqué serait préférable. Et il avait raison
  • Les TUI offrent de bons raccourcis clavier et sont accessibles directement depuis l’endroit où l’on lance les commandes, ce qui les rend adaptés aux tâches rapides

• J’aime bien Claude Code, mais je trouve que la structure TUI basée sur React est vraiment inefficace

  • La dégradation des performances est particulièrement marquée lorsqu’on fait défiler de longs textes. J’ai l’impression que l’architecture est comme ça depuis le début, et je me demande pourquoi c’est si difficile à corriger
  • Si le rendu est déjà fait en JS, il peut être raisonnable d’utiliser React comme moteur de réutilisation

• J’ai créé mon propre frontend de prompts à partir de Cursor CLI — image
  J’y ai intégré git, diff et l’historique de chat, et grâce à Tailscale j’y accède facilement même depuis mon téléphone.
  Il reconnaît mes règles et peut faire des grep dans le projet, donc l’ergonomie est vraiment excellente