Pourquoi les TUI reviennent en force

• Les TUI attirent de nouveau l’attention grâce à leur retour immédiat, leur facilité d’automatisation et leur capacité à fonctionner entre systèmes d’exploitation, et des outils comme Claude et Codex ont eux aussi rencontré un grand succès en ligne de commande
• Les GUI natives de Windows, Linux et macOS alourdissent la charge pour les développeurs comme pour les utilisateurs en raison, respectivement, de stratégies d’API instables, d’une dispersion des toolkits et des environnements, et d’un affaiblissement de la cohérence avec les anciennes directives
• Pour les applications Electron, le problème le plus important n’est pas tant l’usage mémoire que le manque de cohérence visuelle et les lacunes dans les workflows centrés sur le clavier ; l’intégration des menus et des raccourcis s’est aussi affaiblie
• Il y a bien eu des tentatives de créer une nouvelle pile UI, comme Flutter UI chez Google et GPUI chez Zed, mais sans bonne intégration au système d’exploitation, un moteur de rendu rapide ne suffit pas
• Dans une bonne interface, l’élément clé est la cohérence, qui permet à l’utilisateur de moins réfléchir ; les développeurs ainsi que les créateurs de systèmes d’exploitation et de toolkits doivent davantage investir dans la théorie de l’UI et dans des toolkits accessibles

---

Pourquoi les TUI attirent à nouveau l’attention

• Omarchy de DHH est composé d’un mélange de TUI, de web apps et d’applications natives de style gnome, et les TUI y sont utilisées pour leur retour immédiat et leurs « geek points »
• Il y a environ dix ans, on a observé une évolution similaire dans les éditeurs de code
  • On est passé d’éditeurs natifs comme BBEdit, Textmate, Notepad++ et Sublime à des applications basées sur Electron comme Atom, VSCode et leurs dérivés
  • Les utilisateurs aux préférences les plus marquées se sont tournés vers vim ou emacs, obtenant un retour immédiat et une excellente ergonomie au prix d’une courbe d’apprentissage très raide

Pourquoi les GUI natives se sont affaiblies

• Windows

  • Windows n’a pas su établir une stratégie cohérente pour ses bibliothèques GUI et a répété le même schéma : lorsqu’une API n’aboutissait pas, une autre était créée
  • Jeffrey Snover explique dans Microsoft hasn’t had a coherent GUI strategy since Petzold que MFC, OLE, COM et ActiveX ont diffusé de la complexité dans l’ensemble du développement Windows
  • Microsoft est ensuite passé par WinForms, WPF, Silverlight, WinUI et MAUI sans parvenir à imposer une solution, et beaucoup d’applications desktop, en entreprise comme pour le grand public, reposent encore sur Electron
  • La dernière période où l’ensemble de Windows était visuellement intégré de façon cohérente correspond plutôt à Windows 98 ou Windows 2000
  • Dans Windows Native App Development Is a Mess, Domenic Denicola estime que le coût de recréer le système d’exploitation et les API UI tous les quelques années est élevé et que, avec les tentatives de sandboxing et de dépréciation de fonctionnalités, chaque nouvelle couche laisse des trous où certaines choses possibles dans les anciens frameworks ne le sont plus

• Linux

  • L’incohérence de l’UI sous Linux est proche d’une conséquence de sa conception même, chaque équipe ayant la liberté de poursuivre des objectifs différents
  • GTK et Qt sont devenus les principaux frameworks, tous deux orientés vers le développement natif cross-platform, même si leur usage le plus répandu reste Linux
  • Des applications Linux créées avec différents toolkits peuvent encore sembler relativement harmonieuses côte à côte, alors que les multiples frameworks de Windows n’atteignent pas ce niveau de cohésion
  • Comme il existe trop de combinaisons de distributions, d’environnements desktop et de matériel, les tests sont difficiles, ce qui pousse beaucoup d’entreprises à ne pas développer d’applications Linux natives
  • Les entreprises prennent généralement en charge Linux via Electron, ou laissent la communauté open source s’en charger quand une API publique existe

• macOS

  • Les Human Interface Guidelines d’Apple représentaient un standard si fort qu’elles étaient citées dans les cours d’interface utilisateur partout dans le monde
  • Xerox PARC et Apple sont souvent cités parmi les institutions qui ont le plus étudié ce qu’est une bonne interface homme-machine
  • Récemment, Apple a évolué dans une direction qui rompt avec la cohérence de ses anciennes directives
  • macOS va dans le sens d’ignorer la loi de Fitts, de rendre le redimensionnement des fenêtres presque impossible, de laisser ces problèmes persister malgré des tentatives de correction et d’ajouter des icônes à tous les menus
  • Il devient difficile de considérer macOS comme un refuge où les designers peuvent encore travailler sereinement

Les limites des applications Electron

• Le problème le plus souvent cité est l’usage mémoire, mais celui-ci a eu tendance à diminuer au cours des dix dernières années
• Les problèmes plus importants sont le manque de cohérence visuelle et l’insuffisance des workflows centrés sur le clavier
• Même dans un environnement avec un MacBook Pro doté de 64 Go de RAM, le Dock contient à la fois 8 applications natives et 6 applications Electron
  • Applications natives : TextMate et les utilitaires système de macOS
  • Applications Electron : Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
• Dans des applications comme Cursor et VSCode, après avoir demandé une fonction dans le panneau d’agent, il n’est pas naturel de se déplacer uniquement au clavier vers la liste des agents du panneau latéral ni d’archiver un élément
• Ce type d’action devrait être possible de la même manière dans toutes les applications macOS, mais même lorsqu’un raccourci existe, il n’apparaît pas toujours dans le menu
• Au cours des dix dernières années, les développeurs ont eu tendance à oublier d’ajouter aussi dans les menus les actions possibles dans une application, ce qui est lié à une architecture où l’application est implémentée comme du HTML dans une sandbox
• Slack gère cet aspect mieux que d’autres applications Electron, sans pour autant être irréprochable

Les tentatives de recréer une nouvelle pile UI

• Avec Dart, Google voulait créer un toolkit UI pour un nouveau système d’exploitation et de nouveaux appareils, sans héritage d’Android
• Google souhaitait un nouveau toolkit nommé Flutter UI, mais a abandonné le projet avant le lancement du produit réel
• Ce type de tentative ne peut réussir qu’avec une position dominante ou une part de marché suffisamment importante
• Zed a adopté une approche similaire en Rust en créant GPUI, sa propre bibliothèque de rendu GPU, pensée pour le cross-platform
• GPUI est rapide, mais son intégration avec le système d’exploitation hôte ne suffit pas à elle seule, si bien que les développeurs doivent eux-mêmes ajouter les bindings nécessaires
• Un moteur de rendu lent mais bien intégré au système d’exploitation vaut mieux qu’un moteur rapide

Le vide que les TUI viennent combler

• Dans un contexte qui rappelle le déclin d’Apple Automator, les TUI redeviennent importantes comme interfaces automatisables
• Les TUI sont aussi relativement faciles à exécuter à distance et n’exigent pas de dépendre du pénible X forwarding
• Quand les toolkits UI natifs échouent, on revient aux fondamentaux, et les TUI réapparaissent alors comme une option pertinente
• Claude et Codex ont rencontré un grand succès en ligne de commande, et les utilisateurs peuvent se concentrer sur l’interaction elle-même plutôt que sur le système d’exploitation environnant
• Grâce aux TUI, on peut manipuler du code et des applications sur des machines cloud, ou se connecter à distance depuis un iPad à une machine équipée d’un GPU
• Les TUI comblent le vide laissé par Apple et Microsoft dans un environnement où chaque application finit par avoir une apparence différente
• Des apparences variées peuvent convenir à l’art ou au jeu vidéo, mais elles ne sont pas adaptées à un objectif où l’interface doit s’effacer pour laisser l’utilisateur faire son travail

La direction à prendre

• Dans Bring Back Idiomatic Design, John Loeber estime qu’une case à cocher est elle aussi une interface pour interagir avec un système, et qu’une bonne interface est celle qui fait moins réfléchir l’utilisateur
• Les utilisateurs interagissent avec beaucoup de choses, ils ont donc besoin d’interfaces homogènes offrant une expérience cohérente
• Si Command+C est le raccourci pour copier, il doit fonctionner partout ; devoir se souvenir qu’ailleurs il faut CTRL+Shift+C ou clic droit → copier est inconfortable
• Tous les développeurs devraient apprendre non seulement à construire des logiciels, mais aussi la théorie qui permet d’améliorer les interfaces utilisateur en général
  • Nielsen
  • Norman
  • Johnson
• Il faut cesser de traiter le design utilisateur, dans les cursus de génie logiciel, comme une soft skill négligeable
• Si, dans un quelconque cursus, l’UI n’est pas comprise, le projet devrait être considéré comme un échec ; dans les cursus HCI, il faudrait viser une UI parfaite
• La création d’une bonne UI consiste surtout à comprendre les besoins ; la programmation elle-même est déjà en train d’être automatisée
• Les créateurs de systèmes d’exploitation et de toolkits doivent encourager les investissements dans des toolkits accessibles que les développeurs ont envie d’utiliser, tout en abaissant les barrières à l’entrée
• Il ne s’agit pas forcément d’exiger absolument le cross-platform, mais l’existence d’au moins une telle solution pourrait aider à réduire la dépendance à Electron et aux TUI

[colus001]

Je pense moi aussi que la scène du développement est excessivement sensible aux effets de mode. Les TUI sont simplement poussées par des entreprises qui n’ont ni la capacité ni la volonté de créer correctement des GUI, et je me demande bien combien de personnes utilisent réellement des TUI.

[GN⁺]

Avis sur Lobste.rs

• J’aimerais que les gens fassent plutôt des applications natives. Les TUI donnent l’impression de combiner les défauts des interfaces en ligne de commande et des vraies GUI
  Tous les programmes TUI doivent réimplémenter eux-mêmes le défilement, donc même si le terminal prend en charge le scroll au pixel près, les programmes TUI ne proposent qu’un défilement ligne par ligne, avec en plus des comportements différents selon les cas. Le scrollback de senpai ne fonctionne pas comme les autres programmes que j’utilise, et je m’y perds sans arrêt
  Il n’existe pas non plus de moyen d’indiquer au terminal que l’interface contient autre chose qu’un simple panneau de texte, donc la sélection de texte casse souvent. On peut contourner ça en interceptant les événements de souris, mais ce n’est pas terrible non plus. Dans un client IRC en TUI, je devais appuyer sur un raccourci pour masquer les panneaux annexes de chaque côté juste pour pouvoir sélectionner du texte, et c’était franchement idiot
  La contrainte d’être calé sur une grille limite énormément les possibilités de mise en page et de design. Ça me fait penser à ces façons de styliser des éléments pour qu’ils ressemblent à des boutons cliquables, ou à des choses comme les menus contextuels. J’en avais déjà parlé pour m’en plaindre ici
  À mes yeux, la prolifération des TUI est la conséquence regrettable du mauvais état des frameworks GUI traditionnels. Les frameworks TUI sont relativement stables, et même en utilisant des outils très anciens, ça ne dérange pas tant que ça. On utilise encore souvent des programmes ncurses aujourd’hui, alors qu’il est difficile d’imaginer utiliser encore des programmes Motif
  En face, les frameworks GUI offrent peu d’options et demandent bien plus de maintenance. Les environnements de bureau changent, et les attentes vis-à-vis des GUI augmentent. Je pense que l’accessibilité des TUI est vraiment mauvaise, sans en être totalement certain. Et tout évolue sans cesse : on développe en GTK2, puis c’est obsolète ; on migre vers GTK3, puis on nous dit de passer à GTK4
  D’un point de vue cynique, il y a aussi d’autres facteurs dans des choses comme Omarchy. Un GUI classique comme xfce4-taskmanager est banal, mais un TUI comme btop a l’air ultra hacker. Les gens aiment l’esthétique du terminal (voir /r/unixporn) et semblent prêts à sacrifier de l’utilisabilité pour l’ambiance. Il suffit de voir btop faire réellement disparaître la liste des processus en fondu

  • Après avoir fait du développement web pendant longtemps, j’avais envie d’essayer le développement d’applications natives. J’ai regardé ce qu’il fallait pour faire une appli GNOME, et le côté centré sur C++ m’a assez vite découragé
    J’espérais que la barrière à l’entrée serait plus basse aujourd’hui. Ça me paraît peu convaincant dans un monde où la plupart des développeurs sont formés sur des langages de haut niveau, et la complexité de C++ a tendance à m’intimider
  • Petite digression : je ne comprends pas pourquoi tant de clients de chat rendent l’historique illisible quand on le copie-colle. Sur Discord, par exemple, on obtient quelque chose comme ça
    [
    20:41
    ]
    username1
    :
    message1
    [
    20:42
    ]
    username2
    :
    message2
    Le client Matrix Nheko ne permet même pas de sélectionner plus d’une ligne à la fois
    Alors que les clients IRC proposent par défaut quelque chose comme
    20:41 <username1> message1
    20:42 <username2> message2
  • J’aime les interfaces en ligne de commande, mais moi non plus je ne suis pas fan des TUI. Elles ont leur utilité, mais en pratique ça ressemble surtout à une GUI rugueuse et moche, et ça gaspille souvent de la place dans le terminal
    Parfois ça se justifie, mais dans l’idéal, je pense qu’il vaut mieux les réserver à de petites applis à usage bref, ou à des exceptions comme l’édition de texte
  • Je trouve aussi les TUI un peu faibles, mais comparées à des toolkits UI comme gtk, c’est malgré tout l’option la moins mauvaise. Les applis TUI que j’aime sont extensibles, réactives et bien intégrées à la ligne de commande Linux
    Par exemple, lf, tig, kakoune s’accordent bien avec les scripts shell, au point qu’on peut réutiliser les mêmes scripts et étendre les fonctionnalités dans les trois applis. Comme elles tournent toutes dans alacritty, on peut aussi créer des hyperliens qui fonctionnent dans les trois applis et plus largement dans le shell
    Si je pouvais rêver, j’aimerais un toolkit GUI minimaliste monochrome permettant une intégration à la Emacs ou acme
  • Globalement je suis d’accord, mais je voulais quand même signaler que Tk continue discrètement à faire son chemin et reste utile aujourd’hui. gitk en est un bon exemple

• Je ne vois pas bien en quoi les TUI seraient « faciles à automatiser ». Ce ne sont pas juste des GUI affichées dans la console ?

  • Beaucoup de TUI proposent à l’ouverture des flags qui se comportent comme un langage de script. Et puis il est plus simple et moins coûteux pour un LLM d’interagir avec une interface textuelle qu’avec une vraie GUI native ou une appli Electron à forte composante JavaScript

• Cet article passe à côté de la raison principale pour laquelle les TUI sont « revenues ». J’ai d’ailleurs des doutes sur cette affirmation, mais il semble vrai qu’elles ont récemment gagné en popularité avec la vague de vibe coding autour d’agents de code comme Claude
  Les développeurs aiment les solutions faciles. C’est simplement plus facile de créer une TUI cross-platform qu’une GUI
  C’est aussi pour cette raison que les applications web ont pris autant d’ampleur : il était plus simple de créer des applis cross-platform avec les outils du navigateur, et Electron s’inscrit dans la même logique en retirant au moins la contrainte du support cross-browser. Concevoir des interfaces responsives, rendre une UI de manière cross-platform, traiter les entrées utilisateur, en particulier en tenant compte de l’accessibilité : tout cela est difficile. Donc dès qu’une solution facilite ces aspects, les développeurs se ruent dessus
  Il y a aussi eu récemment des évolutions qui ont facilité la création de TUI. Le support cross-platform des fonctions avancées s’est amélioré, des bibliothèques populaires sont apparues pour abstraire les détails complexes, et tout cela semble avoir contribué à la récente renaissance des TUI
  Pour le reste, plusieurs arguments de l’article me semblent discutables. Par exemple, l’auteur reproche aux applis Electron leur manque de cohérence, mais parmi les TUI populaires, il y a très peu de cohérence en dehors de quelques conventions. Les agents de code ont adopté des raccourcis similaires, mais surtout parce qu’ils ont copié Claude comme source commune. Ces raccourcis ne s’étendent pas vraiment au-delà des agents de code, et la plupart des TUI que j’utilise ont des raccourcis et un langage visuel assez différents

  • Je ne vois pas bien ce que veut dire « créer une UI responsive, c’est difficile ». Ça sonne comme un sujet web ; certaines idées du web peuvent certes être pertinentes, mais pour les GUI natives, ça me paraît hors sujet. Tu voulais simplement parler de « faire une bonne UI » ou de « créer un toolkit UI » ?
    La phrase « rendre une UI en mode cross-platform est difficile » me laisse aussi perplexe. Oui, il faut une couche de compatibilité et une implémentation par plateforme, mais ça ne me semble pas tellement plus dur que de supporter une seule plateforme. À moins bien sûr que les plateformes ciblées aient des modes de rendu tellement différents qu’il soit difficile de concevoir une API commune ; mais au niveau du simple affichage de pixels à l’écran, ça ne devrait pas être le cas. Il faut gérer des éléments comme l’échelle d’affichage, mais au-delà ça devrait rester assez direct, sinon il y a toujours SDL
    Je suppose que tu parlais plutôt du fait de rendre l’UI « native » sur toutes les plateformes. Là, il faut peut-être utiliser le toolkit GUI natif préféré de chaque plateforme, et ceux-ci sont non seulement très différents, mais aussi bien plus volumineux et moins stables que des API de rendu bas niveau. Pour ce genre de choses, la vie est trop courte. Je laisserais éventuellement quelques réglages au niveau de l’appli pour la palette ou certains aspects graphiques, mais pas plus. Je n’ai pas envie de perdre du temps à lire les réglages graphiques de chaque système d’exploitation
    Et la phrase « traiter les entrées utilisateur, surtout l’accessibilité, c’est difficile » me semble aussi étrange. Écouter les événements clavier et souris, c’est trivial. Côté accessibilité, il faut une vraie navigation au clavier, ce qui est important aussi pour l’utilisabilité générale, ainsi que la prise en charge des raccourcis standards et personnalisés, mais dans l’ensemble ça me paraît bien plus simple que le reste
    La prise en charge des lecteurs d’écran peut être difficile selon les API des plateformes concernées et leurs différences, mais c’est plus un problème de rendu que de saisie

• Les TUI ne sont pas tant un « retour » qu’un symptôme de la perte du savoir-faire en programmation de GUI natives : on fait au mieux avec les outils qu’il nous reste. C’est le résultat d’un manque de développement cohérent et d’investissement
  À part quelques exceptions lumineuses comme Qt, la civilisation des UI s’est effondrée et nous avons l’impression de vivre après l’apocalypse
  Ça fait écho à la conférence Preventing the Collapse of Civilization, et maintenant que l’IA écrit une bonne partie du code, je crains que cet effondrement des savoirs ne s’aggrave encore

  • Chaque fois que ce sujet revient sur lobste.rs, je finis par intervenir, donc autant le faire ici aussi. Tous les « empires » des GUI s’effondrent sous nos yeux : Windows, macOS, GTK, les produits Mozilla, tous
    On dirait qu’il nous faut une sorte de After Virtue de l’informatique, et peut-être que la présence en ligne de Blow joue déjà ce rôle. Quoi qu’il en soit, l’époque des interfaces informatiques cohérentes, respectueuses des utilisateurs, et qui récompensaient l’apprentissage et le soin me manque

• Cet article me semble assez creux au fond ; on a surtout l’impression que son auteur pense que tout le reste est nul
  S’il y a une chose à dire, c’est que Emacs est une excellente plateforme pour les interfaces textuelles, au clavier, à boutons, et même riches en médias

• C’est probablement parce que les gens ont commencé à utiliser des bibliothèques TUI en Go, Rust, et maintenant Zig, au lieu de ncurses. Cela dit, ncurses a quand même permis de résoudre d’horribles problèmes de portabilité
  Ensuite, les gens se sont mis à créer de nouveaux terminaux et à pousser aussi cette pile technique. En partie parce qu’on pouvait désormais le faire en Go, Rust ou Zig plutôt qu’en C
  Si on donne aux gens de bonnes options, plus amusantes et moins pénibles que C et C++, il est logique qu’ils se mettent à écrire du code plus récent et plus utile

• La vraie raison du retour des TUI, c’est qu’en 2026, pour distribuer une GUI signée et notariée, il faut payer Apple, et sous Windows il faut aussi payer une autorité de certification

  • Les binaires TUI natifs n’ont pas le même problème ?

• Petite correction de détail : la bibliothèque UI accélérée par GPU de Zed n’est pas l’API cross-platform wgpu, mais gpui

• Je ne sais pas si l’article démontre vraiment sa thèse, mais en tant que personne ayant connu l’époque MS-DOS et ayant toujours aimé les TUI, je vais quand même donner mon avis. Si vous avez utilisé afl-fuzz, vous voyez probablement de quoi je parle
  En théorie, les TUI auraient dû bien mieux réussir sous Linux. Il existait un public technique amateur d’esthétique textuelle, ainsi que « l’avantage » d’environnements GUI rustiques et incohérents. Il y a même eu une époque où faire simplement fonctionner correctement une carte graphique avec le serveur X relevait déjà du problème
  En même temps, pendant des décennies, les développeurs de logiciels *nix ont eu l’impression d’être obligés de supporter des types de terminaux anciens et exotiques. Comme si c’était dramatique qu’une application ne s’affiche pas correctement sur un DECwriter, et avec ce genre de contraintes, il était difficile de faire de bonnes TUI
  À l’époque MS-DOS, des entreprises comme Microsoft, Borland ou Norton avaient réussi à produire des interfaces textuelles fonctionnelles et réactives. Sous Linux, pendant longtemps, le « sommet » de la conception TUI a été le monstre qu’est menuconfig, et en plissant un peu les yeux on peut à peine qualifier vim de TUI. À l’époque où les gens utilisaient réellement des consoles en mode texte, la seule bonne TUI Linux dont je me souvienne vraiment était Midnight Commander, un gestionnaire de fichiers inspiré de Norton Commander