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

Commentaires Hacker News

• Si on regarde juste les chiffres, la vraie raison de la popularité des TUI, c’est Claude Code ; le reste ressemble à du bruit de fond en comparaison.
  Ce qui m’a d’abord donné envie de créer une TUI, c’était l’idée de livrer une appli via SSH. Une appli SSH ressemble au navigateur sur un point : elle ne demande aucune installation locale.
  Si je m’amuse autant avec https://pico.sh, c’est en grande partie parce que le déploiement d’une TUI ne demande absolument aucune intervention de l’utilisateur.

  • Je ne pense pas. L’augmentation du nombre de nouveaux programmes TUI semble avoir commencé avant que Claude Code ne décolle vraiment.
  • Claude Code a sans doute amplifié la tendance d’un facteur cent, mais les TUI augmentaient déjà fortement à l’époque de go fzf, Rust ratatui et Python Rich.
    J’imagine que cela vient à la fois de l’envie d’échapper aux interfaces lourdes basées sur le navigateur, et de la curiosité de tester les limites du rendu dans le terminal.
  • Je comprends l’idée de distribuer des applis via SSH, mais c’est dommage que l’émulateur de machine à écrire à port série ait survécu jusque-là.
    Au lieu de construire de nouveaux systèmes avec des technologies nouvelles et intéressantes, on fabrique des émulateurs de machine à écrire accélérés par GPU. C’est une forme étrange, mélange de nostalgie et d’aveuglement technique.
    On peut faire passer n’importe quel protocole au-dessus de SSH. J’aimerais plutôt qu’on avance vers quelque chose qui dessine sur un affichage bitmap distant.
    X Window n’était pas admirablement conçu, mais il avait la transparence réseau, et le devdraw de Plan 9 était un moteur de rendu où les programmes graphiques distants téléversaient leurs assets, puis envoyaient des commandes de dessin de lignes via RPC.
  • La motivation qui me fait préférer une appli TUI à une CLI pure ou à une GUI, c’est toujours le fait qu’on puisse l’utiliser via SSH.
  • Je me demande si l’idée est que les TUI sont populaires parce que tout le monde essaie d’imiter Claude Code, ou si c’est que Claude Code a rendu le développement de TUI plus facile.

• Avec vim, la seule vraie difficulté, c’est qu’il faut tendre les doigts jusqu’à Escape pour revenir en mode commande, qui est pourtant l’essence même d’un éditeur modal.
  Le flux idéal, c’est d’éditer vite puis de revenir immédiatement en mode commande ; l’usage d’Escape est un vestige historique qu’il faut reconnaître comme tel.
  La solution, c’est de remapper globalement CapsLock en Escape. Sous Linux et macOS, ça se fait via les réglages GUI ; sous Windows, créer ou modifier la clé du registre prend une minute.
  Pour le reste, il suffit d’apprendre les bases avec vim-tutor, puis de chercher quand une tâche prend trop de temps, donc je ne vois pas très bien où serait la fameuse courbe d’apprentissage. Le vrai problème, c’est qu’on s’habitue trop vite à l’édition modale, au point que les environnements qui en sont dépourvus donnent l’impression de revenir à l’âge de pierre.

  • Quand on doit souvent passer d’un ordinateur portable à l’autre, remapper CapsLock en Escape crée pas mal de friction. La mémoire musculaire gêne en permanence.
  • Je n’ai jamais vu quelqu’un revenir en arrière après avoir remplacé CapsLock par Escape. La différence ressentie est totale.
    Aujourd’hui, je pense même que si vim a besoin de hjkl, c’est surtout parce que la disposition des claviers est mauvaise pour les flèches. Les machines à écrire n’avaient pas de flèches, mais sur les ordinateurs elles sont essentielles.
    La barre d’espace n’a pas besoin d’être si grande, ni d’être utilisée par les deux pouces. Ce serait bien mieux de déplacer un petit groupe de flèches vers une partie à gauche ou à droite de la barre d’espace.
    Le hack hjkl ne marche que dans les éditeurs pour hackers, alors qu’on utilise aussi énormément les flèches dans les logiciels grand public, et la disposition actuelle est très mauvaise pour les mains. J’ai commencé à avoir des inflammations à force d’essayer d’appuyer sur les flèches avec le pouce sans bouger toute la main.
  • Étrangement, j’aime bien que Esc soit loin, non pas pour l’efficacité mais pour des raisons ergonomiques.
    Ça oblige à lever la main, à quitter la position de repos puis à la remettre, ce qui réduit des points de RSI qui sinon s’accumuleraient passivement.
    Pour la même raison, l’autre main utilise aussi souvent les touches fléchées. Bien sûr, j’utilise quand même assez souvent hjkl.
  • Sous Windows, PowerToys inclut un outil de remappage clavier plutôt correct.
    https://github.com/microsoft/PowerToys
  • Les doigts sont déjà en position de repos, donc il suffit de mapper jj et c’est réglé.
    Et Ctrl + [ correspond à Esc dans les terminaux/ASCII standard, donc ça peut être un peu plus pratique que d’aller chercher la touche Esc.

• Ce qui ressemble à une mode des TUI, ce sont les cendres laissées par l’effondrement des intérêts égoïstes des éditeurs d’OS.
  Il n’existe aucun bon UI générique. Le navigateur est ce qu’on a de mieux et il a eu pas mal de succès, mais le sandboxing le rend inadapté, ou du moins pénible, pour tout ce qui a besoin d’accéder à des fichiers locaux ou au réseau. Et l’overhead pour lancer quelque chose de simple est absurde.
  L’accès distant est encore pire. On se retrouve avec des problèmes du genre : est-ce qu’une appli qui tourne sur un hôte Windows est accessible depuis un Mac, est-ce qu’on peut la forwarder via un tunnel, etc.
  La TUI est un protocole générique simple qui fait ce qu’il faut, et la dimension distante y est native. Ce qu’on utilise en local fonctionne naturellement aussi au-dessus d’une connexion SSH.
  C’est aussi un énorme doigt d’honneur adressé aux éditeurs d’OS qui pensaient gagner en rendant tout incompatible ou en enfermant les gens dans leur écosystème.

  • Les TUI sont faciles à comprendre pour les utilisateurs, efficaces non seulement en ressources mais aussi dans l’interaction, et agréables à regarder dans un bon terminal.
    Notcurses et Ratatui ont beaucoup aidé ncurses.
  • C’est parce que les environnements GUI modernes et absurdes ont échoué qu’on revient sans cesse à des environnements de bureau minimalistes comme xfce4.
    Windows 11 en est un très bon exemple : toute cette exagération n’est vraiment pas nécessaire.

• J’aimerais que les TUI ne reviennent pas. N’importe quel jour, je choisirai une interface web plutôt qu’une TUI.
  Pas besoin d’installer des polices trop malignes, ni de tripoter les réglages du terminal pour que l’affichage soit correct, ni de deviner les raccourcis de navigation que le créateur estimait supérieurs.
  On a aussi une vraie édition de texte avec la navigation textuelle standard de l’OS, une meilleure intégration avec les gestionnaires de mots de passe, les expanseurs de texte, etc.
  Je vis dans la CLI et j’ouvre le terminal avec un seul raccourci, mais la technologie a beaucoup progressé depuis l’époque où le terminal était l’unique option, et il existe aujourd’hui de bien meilleurs choix pour construire des interfaces.

  • Les interfaces web ne valent pas mieux. Elles sont conçues pour l’esthétique plutôt que pour la fonctionnalité, et chacune a ses propres conventions UI à apprendre.
  • J’ai utilisé vim et Emacs pendant des décennies, mais depuis que je suis passé à la GUI il y a quelques années, je n’ai aucune envie de revenir en arrière.
    Toute cette mode des TUI me semble juste être une tendance de mode.

• C’est parce que personne n’investit dans le développement d’interfaces natives. Electron prouve que les entreprises adopteraient une pile GUI facile à utiliser si elle existait.

  • L’article dit que Google a abandonné avant de sortir un vrai produit, mais j’ai l’impression que le travail sur Flutter continue et que son adoption progresse.
  • Le pire moment, c’est quand on veut faire un petit utilitaire, par exemple un outil qui cherche des fichiers avec une expression régulière.
    Pour une grosse appli, le temps de packaging et de distribution reste une petite partie du total, et la taille des fichiers importe peu, mais pour une petite appli ce n’est pas le cas.
    Sur Windows, une appli peut être simple : un petit binaire ouvre un formulaire, se lance au double-clic et ne demande aucune installation.
    Sur Linux, pour faire la même chose, rien ne garantit que GTK ou Qt soit installé ; pour en faire un exécutable autonome, il faut en pratique embarquer presque tout l’OS. Du coup, la taille explose.
    Python pose aussi problème pour les utilisateurs Windows, parce qu’il faut soit qu’ils aient Python, soit embarquer l’interpréteur.
    La seule alternative vraiment viable, c’est quelque chose comme Java, avec un unique fichier .jar exécutable partout, mais Oracle a changé la licence et JavaFX n’est plus inclus avec Java. Swing l’est toujours.
    Je veux juste afficher une barre de menus avec des raccourcis clavier ; je ne comprends pas pourquoi il n’existe pas une sorte de VM de barre de menus qui donne accès à une barre de menus sur tous les OS.
    Envoyer tout un navigateur avec Electron est stupide. Il faudrait que l’utilisateur installe une plateforme, comme une version desktop des applis Flash, et que toutes les applis s’appuient dessus.
    Distribuer des jeux DOS est peut-être plus facile que des applis desktop. Les gens qui veulent lancer des jeux DOS ont probablement déjà un émulateur DOS installé.
  • C’est moins un manque d’investissement qu’un problème de ne pas avoir construit quelque chose de correct.
    Il faut un framework facile à utiliser, cross-platform, open source et, si possible, utilisable depuis le langage de programmation de son choix.
  • Zed l’a effectivement fait. Il a ses fans, mais vu l’effort énorme consacré à construire un système GUI depuis zéro, on n’a pas l’impression que l’adoption explose.
  • wxWidgets et Qt ne sont-ils pas corrects ? GTK 2 et 3 aussi ; à partir de la 4, c’est moins convaincant. Beaucoup d’applis utilisent l’un d’eux, souvent via des bindings Python.
    Le problème plus large, c’est la main-d’œuvre. Comme il y a beaucoup de gens qui savent faire du développement web, on veut réutiliser cette main-d’œuvre pour le desktop aussi, et si le desktop est en JavaScript avec Electron, c’est bien plus simple.

• J’ai du mal à comprendre les interfaces terminal qui essaient de recréer des fonctions de GUI. Les interfaces informatiques ne sont-elles pas censées s’améliorer ?
  On n’a plus besoin de se limiter à une grille de caractères pour faire semblant de dessiner des lignes et des formes. Sans terminaux non standard comme Kitty ou iTerm, on ne peut même pas afficher d’images.
  C’est dommage qu’il n’existe pas un excellent système d’UI streaming cross-platform. Le web est déjà très bien à sa manière, mais il pourrait clairement exister quelque chose de meilleur pour cet usage. Flutter est correct, mais manque d’aspect à la demande et reste trop lié à Dart.

  • C’est dû à l’échec des environnements GUI modernes.
    Les gens veulent une GUI, mais finissent par devoir contourner le problème avec une sorte de GUI dans une TUI.
    Ils veulent quelque chose de portable, exécutable à distance, plus sûr sans devoir exposer de sockets, et qui n’oblige pas à démarrer tout un bureau.
    Les fenêtres rootless sont pratiquement mortes ; il ne reste que les interfaces web avec tous leurs problèmes, ou les TUI qui fonctionnent avec la seule connexion SSH que tout le monde possède déjà.
    Avant, on pouvait bricoler quelque chose avec Tcl/Tk et ouvrir une fenêtre via X Window, mais aujourd’hui ce n’est plus facile et plus personne n’utilise X distant.
    Le plus petit dénominateur commun, c’est SSH, et seules survivent les choses qui s’y adaptent.
  • À propos de l’affichage d’images, Sixel est pris en charge par beaucoup de terminaux[0].
    Plusieurs des terminaux cités comme non compatibles reposent aussi sur GNOME VTE, et la prise en charge est en cours ; à voir le bug tracker, c’est presque terminé.
    Cela inclut aussi xterm, qui est probablement le terminal le plus standard sur X11.
    [0] https://www.arewesixelyet.com/
  • Les TUI existent parce qu’elles permettent de finir le travail facilement. Dès qu’on construit une vraie GUI, la base de code devient soudainement bien plus complexe.
    Il n’y a même pas de toolkit GUI solide et fiable ; ils sont tous remplis de bugs et de pièges différents.
    On dit que Flutter est correct, mais cela suppose d’ignorer que le processus même de build d’une appli Flutter est un cauchemar. Flutter lui-même ne donne pas l’impression d’avoir été conçu pour être compilé par n’importe qui ; en pratique, ce sont les distributions qui masquent ce problème.
  • Un système d’UI streaming cross-platform, ça peut s’appeler web/Jupyter.
    Et une UI web n’a pas forcément besoin d’être lourde. HN en est la preuve.
  • C’est parce qu’au-dessus de SSH, le texte est rapide. Les redessins graphiques à la RDP ou VNC sont plus lents et plus pénibles sur la durée.

• Même pour quelqu’un qui garde toujours un terminal ouvert, automatise sa vie avec des scripts Bash et utilise VIM/TMUX, la plupart des TUI ont deux longueurs de retard sur une bonne GUI.
  Navigation arbitraire, raccourcis incohérents, copier-coller cassé, manque d’intégration à l’environnement : voilà les grands classiques.
  Le problème de fond, c’est l’absence d’une plateforme GUI cross-platform correcte, soit bien intégrée aux langages de programmation, soit incluse dans leur bibliothèque standard.
  Swing manque d’accès aux éléments natifs du navigateur, Tk manque de composants navigateur et de glisser-déposer, wxWidgets a une petite communauté et ses bindings semblent avoir dû être ressuscités plus d’une fois.
  Qt peut à tout moment se dégrader au gré de sa volonté de gagner plus d’argent ; je ne considère pas non plus KDE comme si important, et je doute que la communauté KDE puisse porter un fork sur le long terme.
  Il reste donc Electron et les variantes qui collent du JavaScript/CSS sur un composant navigateur avec des callbacks vers un serveur local ; même en laissant de côté l’overhead mémoire et runtime énorme pour des applis mineures, le modèle de programmation lui-même est mauvais.
  Construire un vrai toolkit GUI cross-platform demande beaucoup d’argent et de monde pour l’ergonomie, l’accessibilité, le design, la documentation et les tests. La communauté open source n’y est pas parvenue, GTK est devenu de fait Linux-only, et il n’existe aucun candidat moderne pour remplacer Qt ou Swing.
  Les TUI ne résolvent pas le problème de fond, mais quand on voit les alternatives, on comprend les développeurs qui choisissent une TUI pour faire du cross-platform UI. J’ai l’impression qu’environ 80 % des besoins GUI pourraient aussi être couverts par un toolkit GUI doté d’un renderer TUI.

  • Cela devrait être fourni non pas comme un langage de programmation mais comme une API C.
    Cela permettrait de fournir une API et une ABI stables, et d’avoir des bindings dans de nombreux autres langages sans contournements complexes. C’est encore plus important pour les langages compilés.
    Binder Qt à Python peut être simple, mais pour un langage comme Free Pascal, il faut une bibliothèque C++ intermédiaire qui expose une API C, et il faut en plus distribuer cette bibliothèque avec l’appli.
    Malheureusement, la plupart des toolkits GUI sont écrits non pas en C mais en C++ ou dans d’autres langages, ce qui les rend pénibles à utiliser si le développeur n’emploie pas ce langage. Parmi les solutions grand public, la seule presque entièrement écrite en C est GTK, mais GTK ne se soucie guère de la compatibilité descendante.
    On peut se dire qu’une bibliothèque peut être écrite dans n’importe quel langage tant qu’elle expose une API C, mais si elle n’est pas largement distribuée, on peut vouloir un lien statique. Et hors de C/C++, cela devient un problème.
    Par exemple, j’avais essayé de créer un backend FLTK pour Lazarus[0]. FLTK est une bibliothèque C++ et recommande le lien statique, donc je pensais pouvoir produire un binaire GUI autonome.
    Mais il a d’abord fallu écrire un wrapper C, et sous Linux, faire du lien statique vers une bibliothèque C++ depuis un langage hors C/C++ sans les drapeaux magiques que g++ passe au linker était pénible ; sous Windows, ou du moins avec msys2, c’était impossible, donc j’ai abandonné.
    [0] https://i.imgur.com/W6XbLkr.png
  • Je suis d’accord sur l’essentiel. wxWidgets, en particulier, est vraiment regrettable.
    Sur macOS et Windows, il se rapproche énormément de l’apparence native et il est bien plus agréable à programmer que Qt. Comme utilisateur, et parfois comme programmeur, c’est de loin mon choix préféré pour les GUI multiplateformes.
    À l’inverse, je déteste vraiment, comme utilisateur, les combinaisons Electron ou composant navigateur + JavaScript/CSS + callbacks vers un serveur local. Même si cela signifiait renoncer à certaines fonctions et revenir à la ligne de commande, je préférerais éviter ce genre d’applis.
    Elles ne prennent même pas en charge les raccourcis clavier standard, ont un aspect bizarrement décalé et ralentissent à des moments inattendus.
    Certains frameworks TUI arrivent presque à ce niveau. Le fait qu’on puisse les utiliser sans effort particulier via SSH et autres est appréciable, mais on a l’impression qu’ils résolvent le mauvais problème.
    Plutôt que de tout faire ressembler à un IDE ou fonctionner comme tel, je préférerais des CLI plus ciblées et composables, avec quelque chose comme tmux dont la gestion des fenêtres et la persistance seraient moins catastrophiques.
    Si on construit un simple REPL avec readline, on obtient un comportement standard et prévisible.
    Cela dit, j’aime bien que cette tendance pousse à améliorer les émulateurs de terminal.

• Les TUI que j’ai regardées semblent en grande partie dépendre de NPM.
  C’est étrange, on dirait que les agents n’ont même pas le temps de se réécrire eux-mêmes avec autre chose qu’un incendie de pneu en matière de sécurité.
  Toute cette idée selon laquelle tous ces agents vont prendre le contrôle finit par me faire penser qu’elle vient juste de gens de startup adeptes du passage déchet-vers-déchet, qui n’ont guère à craindre d’autre résultat que de ne pas être assez rapides.

  • 99 % des logiciels autour des LLM restent des débris web instables et cassés.
    Par exemple, OpenCode n’arrive toujours pas à faire correctement quelque chose d’aussi basique que conserver tous les logs de messages et les envoyer dans le même ordre à l’endpoint SSE pour obtenir la réponse suivante, et même en désactivant l’élagage du contexte, il y a encore souvent des prompt cache misses.
  • Go + Lipgloss + Bubbletea est la stack la plus robuste et la plus performante pour créer ou générer des TUI belles et utilisables.
    L’expérience développeur est excellente et il n’y a pas besoin de npm.
  • Ah, l’époque bénie de la sécurité tranquille où tout fonctionnait avec curl | bash.
  • Oui. Les gens les plus enthousiastes à l’idée de mettre de l’IA partout sont presque tous des développeurs JavaScript/TypeScript, généralement en startup, et souvent dans le secteur de l’IA lui-même.

• Le simple fait qu’on laisse des développeurs logiciel concevoir des interfaces utilisateur est étrange.
  On dirait qu’ils sont incapables de construire des interfaces qui ne soient pas textuelles. C’est un peu comme si un plombier concevait une maison en inclinant tous les sols vers le bas pour que la plomberie passe plus facilement.
  S’il faut déplacer et redimensionner plusieurs fenêtres, ils créent une fenêtre de texte ; s’il faut choisir rapidement des options, ils créent une boîte de texte ; s’il faut rédiger vite un document stylé et mis en forme, ils demandent d’écrire encore plus de texte pour le formatage.
  Mais ils ne construisent même pas ensuite une appli qui permette de voir facilement ce texte avec sa mise en forme appliquée.

  • « Laisser » ? La plupart de ces projets TUI open source ont été lancés par une personne ou une petite équipe qui essayait de résoudre son propre problème.
    Ils sont libres de le faire, et il suffit de ne pas les utiliser.
  • À l’autre extrémité, il y a Material et dans une certaine mesure Adwaita.
    C’est joli, mais quasiment inutile dès qu’on sort du développement de styles d’applications ou d’un simple gestionnaire de fichiers.
  • Je ne comprends pas de quoi il est question. Donnez aux développeurs un design system correct et ils peuvent très bien s’en sortir.

• Les TUI sont bien adaptées aux gens qui vivent dans le terminal.
  Pas de distraction liée au contenu visuel, une efficacité extrême au clavier, et maintenant l’IA peut les produire rapidement. Avant, c’était vraiment pénible.

  • Le fait que l’IA puisse les générer rapidement est de loin la raison principale, en fait pratiquement la seule.
  • La conséquence, c’est qu’il y a davantage de personnes habituées à vivre dans le terminal.
    Comme le public des TUI a grandi, les TUI sont devenues plus courantes.
  • Les TUI n’ont pas la place d’ajouter des padding infinis pour avoir un aspect lisse et moderne.
    Et dans 80 colonnes de texte, il n’y a pas grand-chose qu’un chef de produit puisse encore « simplifier ».

[savvykang]

Le fait qu’aucune big tech n’abandonne le navigateur, ce n’est pas justement ça le vrai problème ?

[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