Por que a TUI está voltando
(wiki.alcidesfonseca.com)- TUI voltou a chamar atenção por causa do feedback imediato, da facilidade de automação e da capacidade de funcionar entre sistemas operacionais, e ferramentas como Claude e Codex também tiveram grande sucesso na linha de comando
- As GUIs nativas de Windows, Linux e macOS aumentam o peso para desenvolvedores e usuários devido, respectivamente, a estratégias instáveis de API, fragmentação de toolkits e ambientes, e enfraquecimento da consistência com diretrizes do passado
- Em apps Electron, mais do que o uso de memória, os maiores problemas são a falta de consistência visual e as lacunas em fluxos de trabalho centrados no teclado, além da fraca integração de menus e atalhos
- Houve movimentos para criar novas stacks de UI, como a tentativa de UI com Flutter do Google e a GPUI do Zed, mas um renderizador rápido por si só não basta se faltar integração com o sistema operacional
- Em uma boa interface, a consistência é central porque faz o usuário pensar menos, e desenvolvedores, sistemas operacionais e criadores de toolkits precisam investir mais em teoria de UI e em toolkits acessíveis
O contexto por trás da volta da TUI
- O Omarchy de DHH é composto por uma mistura de TUI, web apps e apps nativos no estilo gnome, e a TUI é usada pelo feedback imediato e pelos “geek points”
- Houve um movimento parecido nos editores de código há cerca de 10 anos
- Houve migração de editores nativos como BBEdit, Textmate, Notepad++ e Sublime para apps baseados em Electron como Atom, VSCode e seus derivados
- Usuários com preferências fortes migraram para vim ou emacs, obtendo feedback imediato e alta usabilidade em troca de encarar uma curva de aprendizado muito íngreme
Por que as GUIs nativas enfraqueceram
-
Windows
- O Windows não conseguiu criar uma estratégia consistente de bibliotecas de GUI e repetiu o padrão de criar outra API sempre que uma não dava certo
- Jeffrey Snover descreve em Microsoft hasn’t had a coherent GUI strategy since Petzold que MFC, OLE, COM e ActiveX espalharam complexidade por todo o desenvolvimento no Windows
- Depois disso, a Microsoft passou por WinForms, WPF, Silverlight, WinUI e MAUI sem sucesso, e muitos apps desktop corporativos e pessoais ainda dependem de apps Electron
- O último período em que o Windows como um todo esteve visualmente integrado de forma consistente foi algo próximo do Windows 98 ou Windows 2000
- Domenic Denicola argumenta em Windows Native App Development Is a Mess que o custo de refazer o SO e as APIs de UI a cada poucos anos é alto e, somado às tentativas de sandboxing e descontinuação de recursos, cada nova camada acaba deixando lacunas em coisas que antes eram possíveis em frameworks anteriores
-
Linux
- A inconsistência de UI no Linux é quase um resultado do próprio desenho do ecossistema, no qual equipes diferentes tiveram liberdade para perseguir objetivos diferentes
- GTK e Qt se tornaram os principais frameworks, e ambos buscaram desenvolvimento nativo multiplataforma, embora o uso mais amplo ainda esteja principalmente no Linux
- Apps Linux feitos com toolkits diferentes podem até parecer razoavelmente bons lado a lado, mas os vários frameworks do Windows não conseguem esse mesmo nível de harmonia
- Como há combinações demais de distribuições, ambientes desktop e hardware, testar é difícil, então muitas empresas não criam apps Linux nativos
- Em geral, as empresas suportam Linux via Electron ou deixam a comunidade open source resolver por conta própria quando existe uma API pública
-
macOS
- As Human Interface Guidelines da Apple eram um padrão tão forte que eram citadas em aulas de interface do usuário no mundo todo
- Xerox PARC e Apple costumam ser lembrados como instituições que pesquisaram o que é uma boa interface humana
- Recentemente, a Apple vem se movendo em uma direção que rompe a consistência com diretrizes do passado
- O macOS está indo na direção de ignorar a lei de Fitts, tornar o redimensionamento de janelas quase impossível, continuar com problemas mesmo após tentar corrigir isso e adicionar ícones a todos os menus
- O macOS já não parece mais um refúgio seguro onde designers possam trabalhar em paz
Limites dos apps Electron
- O problema mais citado é o uso de memória, mas ao longo dos últimos 10 anos o consumo de memória vem caindo
- O problema maior é a falta de consistência visual e a ausência de fluxos de trabalho centrados no teclado
- Mesmo em um ambiente com um MacBook Pro de 64 GB de RAM, há 8 apps nativos e 6 apps Electron juntos no Dock
- Apps nativos: TextMate e utilitários de sistema do macOS
- Apps Electron: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
- Em apps como Cursor e VSCode, depois de pedir uma função no painel do agente, não é natural usar apenas o teclado para ir até a lista de agentes no painel lateral ou arquivá-la
- Esse tipo de ação deveria ser possível do mesmo jeito em todos os apps do macOS, mas às vezes, mesmo quando existe atalho, ele não aparece no menu
- Nos últimos 10 anos, desenvolvedores passaram a ter a tendência de esquecer de adicionar aos menus as ações possíveis no app, e isso se relaciona com uma estrutura em que a aplicação é implementada como HTML dentro de uma sandbox
- O Slack lida melhor com esse aspecto do que outros apps Electron, mas não de forma perfeita
Tentativas de recriar uma nova stack de UI
- O Google tentou criar, junto com Dart, um novo toolkit de UI para um novo sistema operacional e novos dispositivos sem a herança do Android
- O Google queria um novo toolkit chamado Flutter UI, mas abandonou o projeto antes do lançamento de um produto real
- Esse tipo de tentativa só tende a funcionar quando há posição dominante ou participação de mercado grande o suficiente
- O Zed seguiu uma direção parecida em Rust, criando sua própria biblioteca de renderização por GPU, a GPUI, que busca ser multiplataforma
- A GPUI é rápida, mas não oferece sozinha integração suficiente com o sistema operacional hospedeiro, então o desenvolvedor precisa adicionar manualmente os bindings necessários
- Um renderizador lento bem integrado ao sistema operacional é melhor do que um renderizador rápido
A lacuna que a TUI preenche
- Num contexto que lembra o declínio do Apple Automator, a TUI volta a ser importante como interface automatizável
- A TUI também é relativamente fácil de executar remotamente e não exige depender do problemático X forwarding
- Quando os toolkits de UI nativa falham, volta-se ao básico, e com isso a TUI reaparece como opção
- Claude e Codex tiveram grande sucesso na linha de comando, e os usuários podem focar mais na própria interação do que no sistema operacional ao redor
- Pela TUI, também é possível lidar com código e apps em máquinas na nuvem ou acessar remotamente, por um iPad, uma máquina com GPU
- A TUI está preenchendo a lacuna deixada por Apple e Microsoft em um ambiente onde todos os aplicativos parecem diferentes entre si
- Visuais diferentes podem funcionar bem para arte ou jogos de computador, mas não servem bem ao objetivo de uma interface sair do caminho para que o usuário faça seu trabalho
O rumo necessário daqui para frente
- John Loeber argumenta em Bring Back Idiomatic Design que até uma checkbox é uma interface para interagir com um sistema, e que uma boa interface faz o usuário pensar menos
- Como os usuários interagem com muitas coisas, precisam de uma interface homogênea que entregue uma experiência consistente
- Se
Command+Cé o atalho de copiar, ele deveria funcionar em qualquer lugar; exigir lembrar deCTRL+Shift+Cou de clicar com o botão direito → copiar em certos casos é inconveniente - Todo desenvolvedor deveria aprender não só software, mas também a teoria que torna boas as interfaces de usuário em geral
- É preciso parar de tratar design de experiência do usuário como uma soft skill pouco importante nos currículos de engenharia de software
- Em qualquer curso, se a UI não for compreendida, o projeto deveria ser considerado fracassado, e em cursos de HCI o objetivo deveria ser uma UI perfeita
- Criar uma boa UI exige que a maior parte do esforço vá para entender as necessidades, enquanto a programação em si já está sendo automatizada
- Criadores de sistemas operacionais e de toolkits precisam liderar investimentos para produzir toolkits acessíveis que desenvolvedores queiram usar e para reduzir a barreira de entrada
- Não se trata necessariamente de defender suporte multiplataforma a qualquer custo, mas se existir ao menos uma solução desse tipo, isso pode ajudar a reduzir a dependência de Electron e TUI
4 comentários
Eu também penso assim, mas acho que o cenário de desenvolvimento é sensível demais a modas passageiras. O TUI está sendo impulsionado apenas por empresas que não têm capacidade ou vontade de fazer um GUI decente; nem sei quantas pessoas realmente estão usando TUI.
Comentários do Hacker News
Pelos números, o verdadeiro motivo da popularidade das TUIs é o Claude Code; o resto parece quase ruído de fundo em comparação.
O que me fez querer criar uma TUI no começo foi a ideia de distribuir um app via SSH. Um app via SSH se parece com o navegador no sentido de que não exige instalação local.
Um grande motivo de eu brincar bastante com o https://pico.sh é justamente porque a distribuição de TUI não exige nenhuma intervenção do usuário.
Imagino que isso venha tanto do desejo de escapar de UIs pesadas baseadas em navegador quanto da curiosidade de testar os limites da renderização em terminal.
Em vez de criar sistemas novos com tecnologias novas e interessantes, estamos fazendo emuladores de máquina de escrever com aceleração por GPU. É uma forma estranha de mistura entre nostalgia e cegueira técnica.
Dá para trafegar qualquer protocolo por cima de SSH. Eu preferiria ver isso evoluir para desenhar em um display bitmap remoto.
O X Window não tinha um design brilhante, mas tinha transparência de rede, e o devdraw do Plan 9 era um motor de renderização no qual programas gráficos remotos enviavam comandos RPC de desenho de linhas depois de subir seus assets.
A única coisa realmente difícil no vim é que, para voltar ao modo de comando, que é o ponto central de um editor modal, você precisa esticar os dedos até o Escape.
O fluxo ideal é editar rápido e voltar imediatamente ao modo de comando, e vale lembrar que usar Escape é um resquício histórico.
Por isso, basta remapear globalmente o CapsLock para Escape. No Linux e no macOS isso dá para fazer só pela configuração da GUI, e no Windows também termina em um minuto criando ou alterando uma chave no registro.
Fora isso, dá para aprender o básico com o vim-tutor e pesquisar quando surgir alguma tarefa demorada, então não sei bem onde estaria essa tal curva de aprendizado. O problema é se acostumar rápido demais com edição modal e depois qualquer ambiente sem isso parecer idade da pedra.
Hoje em dia acho que o verdadeiro motivo para o vim ainda precisar de hjkl é que o layout do teclado é ruim para as setas. Máquinas de escrever não tinham setas, mas no computador elas são essenciais.
A barra de espaço também não precisava ser tão grande nem ser usada pelos dois polegares. Seria muito melhor mover um pequeno conjunto de setas para parte do espaço à esquerda ou à direita da barra de espaço.
O hack de hjkl só funciona em editores para hackers, mas softwares comuns também exigem muito uso de setas, e o layout atual faz muito mal para as mãos. Comecei a sentir inflamação tentando apertar as setas com o polegar sem mover a mão inteira.
Isso me faz tirar a mão da posição-base e colocá-la de volta, reduzindo pontos de RSI que, de outra forma, iriam se acumulando em silêncio.
Pelo mesmo motivo, com a outra mão também uso bastante as teclas de seta. Claro, também uso bastante hjkl.
https://github.com/microsoft/PowerToys
jje pronto.Além disso,
Ctrl + [é Esc no padrão terminal/ASCII, então pode ser um pouco mais confortável do que esticar a mão até o Esc.As vantagens egoístas das empresas de sistema operacional desmoronaram, e as cinzas que sobraram parecem uma moda de TUI.
Não existe nenhuma UI de propósito geral realmente boa. O navegador é o que chega mais perto e teve bastante sucesso, mas por causa do sandbox ele é inadequado ou traz muita fricção para tarefas que precisam de acesso a arquivos locais ou rede. O overhead para executar algo simples também é absurdamente alto.
O acesso remoto é ainda pior. Surgem problemas como acessar no Mac um app rodando em um host Windows ou encaminhá-lo por uma conexão em túnel.
TUI é um protocolo de propósito geral simples que faz o que você precisa e já nasce remoto. O que funciona localmente também funciona naturalmente sobre uma conexão SSH.
Também é um grande dedo do meio para as empresas de sistema operacional que acharam que a estratégia vencedora era tornar tudo incompatível ou prender você ao ecossistema delas.
Notcurses e Ratatui ajudaram bastante o ncurses.
O Windows 11 é um ótimo exemplo, e todo aquele exagero simplesmente não é necessário.
Eu preferia que a TUI não voltasse. Em qualquer dia, escolho uma interface web em vez de TUI.
Não preciso instalar fontes excessivamente espertinhas, nem mexer em configuração de terminal para algo aparecer direito, nem adivinhar os atalhos de navegação que o autor decidiu que eram os melhores.
Também há edição de texto de verdade com navegação de texto padrão do sistema operacional, além de melhor integração com gerenciador de senhas, expansor de texto e outras ferramentas.
Eu vivo dentro da CLI e abro o terminal com um atalho, mas a tecnologia avançou muito desde a época em que o terminal era a única opção, e hoje existem escolhas muito melhores para criar UI.
Essa onda inteira de TUI parece só uma tendência de moda.
É porque ninguém investe no desenvolvimento de UI nativa. O Electron é prova de que, se existisse uma stack de GUI fácil de usar, as empresas adotariam.
Em um app grande, o tempo gasto com empacotamento e distribuição é uma fração pequena do todo, e o tamanho dos arquivos nem importa tanto, mas em apps pequenos não é assim.
No Windows, um app é fácil: um binário pequeno abre um formulário, roda com duplo clique e não exige instalação.
Para fazer o mesmo no Linux, não há garantia de que GTK ou Qt estejam instalados, então para torná-lo independente você praticamente precisa enviar o sistema operacional inteiro junto. Aí o tamanho do arquivo explode.
Python também é complicado para usuários de Windows, porque eles precisam ter Python ou você precisa enviar o interpretador junto.
A alternativa viável que ainda sobra seria algo como Java, com um único arquivo
.jarexecutável em qualquer sistema, mas a Oracle mudou a licença e o JavaFX não vem mais incluído no Java. O Swing ainda vem.Eu só queria mostrar uma barra de menu com atalhos de teclado; não entendo por que não existe algo como uma VM de barra de menu que permita acessar a barra de menu em todos os sistemas operacionais.
Enviar um navegador inteiro com Electron é idiota. O usuário deveria instalar uma plataforma, tipo uma versão desktop de apps em Flash, e todos os apps usarem isso.
Talvez seja mais fácil distribuir jogos de DOS do que apps desktop. Quem quer rodar jogos de DOS provavelmente já teria um emulador de DOS instalado.
O que faz falta é um framework fácil de usar, multiplataforma, open source e, se possível, utilizável a partir da linguagem de programação escolhida.
O problema maior é pessoal. Como há muita gente que sabe desenvolvimento web, acaba surgindo a vontade de usar essa mesma equipe no desktop, e isso fica muito mais fácil quando o desktop é JavaScript em Electron.
Não entendo muito bem UIs de terminal tentando recriar recursos de GUI. As interfaces de computador não deveriam estar melhorando?
Já não precisamos mais ficar limitados a uma grade de caracteres fingindo desenhar linhas e formas. Sem terminais fora do padrão como Kitty ou iTerm, nem mostrar imagens dá.
É uma pena não existir um ótimo sistema de UI por streaming multiplataforma. A web é ótima à sua maneira, mas claramente poderia existir algo melhor para esse objetivo. Flutter é ok, mas falta ser on-demand e ele é preso demais ao Dart.
As pessoas querem GUI, mas acabam tendo de contornar isso com algo parecido com GUI dentro de TUI.
Elas querem algo portátil, executável remotamente, mais seguro por não precisar expor sockets, e que não exija subir um desktop inteiro.
Janelas sem root praticamente morreram; o que sobrou é interface web com todos os seus problemas, ou TUI, que funciona se todo mundo já tiver uma conexão SSH.
Antigamente dava para improvisar em Tcl/Tk e abrir uma janela com X Window, mas hoje isso não é fácil e ninguém usa X remoto.
O mínimo denominador comum é o SSH, e só sobrevivem as coisas que se encaixam nisso.
Vários terminais citados como sem suporte também são baseados em GNOME VTE, e esse suporte está em andamento; pelo bug tracker, parece quase concluído.
Até o xterm, que no X11 é provavelmente o terminal mais próximo de um padrão, entra nisso.
[0] https://www.arewesixelyet.com/
Também não existe um toolkit GUI realmente sólido e confiável; todos estão cheios de bugs e pegadinhas diferentes.
Dizem que Flutter é ok, mas isso ignora o fato de que o próprio processo de build com Flutter é um pesadelo. O Flutter em si também não parece ter sido projetado para qualquer pessoa compilar; na prática, são as distribuições que escondem esse problema.
E UIs baseadas em web não precisam necessariamente ser pesadas. O HN, por exemplo, não é.
Mesmo para quem vive com o terminal sempre aberto, automatiza a vida com scripts Bash e usa VIM/TMUX, a maioria das TUIs fica dois passos atrás de uma boa GUI.
Navegação arbitrária e atalhos arbitrários, copiar e colar quebrado e falta de integração com o ambiente são exemplos óbvios.
O problema central é que não existe uma plataforma GUI multiplataforma decente que esteja bem integrada às linguagens de programação ou faça parte de uma biblioteca padrão.
O Swing carece de bom acesso a elementos nativos de navegador, o Tk carece de componente de navegador e drag and drop, e o wxWidgets parece ter uma comunidade pequena e bindings que já precisaram ser ressuscitados mais de uma vez.
O Qt pode se degradar a qualquer momento se quiser ganhar mais dinheiro; também não acho o KDE tão importante assim, e duvido que a comunidade KDE conseguiria sustentar um fork no longo prazo.
O que sobra são variações de Electron ou de jogar JavaScript/CSS em cima de um componente de navegador com callbacks para um servidor local; deixando de lado o enorme overhead de memória e runtime até para apps triviais, o próprio modelo de programação é ruim.
Para construir um toolkit GUI multiplataforma decente, é preciso muito dinheiro e muita gente para usabilidade, acessibilidade, design, documentação e testes. A comunidade open source não conseguiu fazer isso, o GTK virou praticamente Linux-only, e não existe um candidato moderno para substituir Qt ou Swing.
TUI não resolve o problema central, mas olhando para as alternativas dá para entender os desenvolvedores que escolhem TUI para UI multiplataforma. Diria até que uns 80% das demandas de GUI poderiam ser atendidas por um toolkit GUI com renderizador TUI.
Assim seria possível ter API e ABI estáveis e fazer bindings para várias outras linguagens sem gambiarras complexas. Isso é ainda mais importante em linguagens compiladas.
Fazer binding de Qt para Python pode até ser fácil, mas para uma linguagem como Free Pascal você precisa de uma biblioteca intermediária em C++ que exponha uma API em C, e o app precisa distribuir essa biblioteca também.
Infelizmente, a maioria dos toolkits GUI não é escrita em C, mas em C++ ou outras linguagens, então, se não for a linguagem favorita do desenvolvedor, o uso vira sofrimento. Entre as opções mainstream, praticamente a única escrita em C é o GTK, mas o GTK quase não liga para compatibilidade retroativa adequada.
Você pode pensar que a biblioteca pode ser escrita em qualquer linguagem desde que exponha apenas uma API em C, mas, se ela não estiver amplamente distribuída, talvez você queira linkar estaticamente. Fora de C/C++, isso vira problema.
Por exemplo, tentei fazer um backend de FLTK para Lazarus[0]. O FLTK é uma biblioteca em C++ e recomenda linkagem estática, então parecia que daria para criar binários GUI autônomos.
Mas primeiro eu precisava fazer um wrapper em C, e linkar estaticamente uma biblioteca C++ a partir de uma linguagem que não é C/C++ sem os flags mágicos que o g++ passa ao linker no Linux era doloroso; no Windows, ou pelo menos no msys2, era impossível, então desisti.
[0] https://i.imgur.com/W6XbLkr.png
Ele chega muito perto da aparência nativa no macOS e no Windows e é bem mais fácil de programar do que Qt. Como usuário e às vezes como programador, é minha opção preferida para GUI multiplataforma.
Já a combinação de Electron ou componente de navegador com JavaScript/CSS e callbacks para servidor local eu realmente detesto como usuário. Prefiro abrir mão da funcionalidade e voltar para a linha de comando a usar apps assim.
Eles não suportam nem atalhos de teclado padrão, têm uma aparência estranha e engasgam em lugares inesperados.
Há frameworks TUI que quase chegaram a esse nível. É bom poder usá-los via SSH e afins sem esforço extra, mas parece que estão resolvendo o problema errado.
Em vez de fazer tudo parecer ou funcionar como uma IDE, eu preferiria usar CLIs mais focadas e componíveis, junto com algo como tmux, mas menos ruim em gerenciamento de janelas e persistência.
Se você criar um REPL simples com readline, obtém um comportamento padronizado e previsível.
Ainda assim, gosto do fato de essa tendência estar impulsionando melhorias em emuladores de terminal.
As TUIs que vi parecem em geral depender de NPM.
É estranho, como se os agentes nem tivessem tempo de se reescrever para algo que não fosse um incêndio de pneus de segurança.
Essa conversa de que todos esses agentes vão dominar alguma coisa me faz pensar que tudo isso foi criado por gente de startup movida a converter lixo em lixo, cuja única preocupação real é não ser rápida o bastante.
Por exemplo, o OpenCode até hoje não acertou nem o básico de manter todos os logs de mensagens e enviá-los ao endpoint SSE na mesma ordem para receber a próxima resposta, e os prompt cache misses continuam frequentes mesmo com a poda de contexto desativada.
A experiência de desenvolvimento também é excelente e não exige npm.
curl | bash.É estranho que se permita a desenvolvedores de software desenhar interfaces de usuário.
Parece que eles não conseguem criar interfaces que não sejam texto. É como se um encanador projetasse uma casa e inclinasse todos os pisos para baixo para facilitar a passagem dos canos.
Se você precisa mover e redimensionar várias janelas, eles fazem uma janela de texto; se precisa escolher opções rápido, fazem uma caixa de texto; se precisa escrever rapidamente um documento com estilo e formatação, fazem você escrever ainda mais texto para formatar.
E ainda assim não criam um app em que esse texto possa ser visto com formatação aplicada de forma fácil.
Eles têm todo o direito de fazer isso, e você não precisa usar.
São bonitos de ver, mas quase inúteis para desenvolvimento de estilo de app ou para qualquer coisa mais complexa do que um gerenciador de arquivos.
TUI é boa para quem vive dentro do terminal.
Não há distrações de conteúdo visual, a eficiência com o teclado é extrema e agora a IA consegue construir isso rapidamente. Antigamente era realmente doloroso.
Como o público de TUI cresceu, TUI também ficou mais comum.
Dentro de 80 colunas de texto, também quase não sobra nada para um gerente de produto “simplificar”.
Não seria errado que, numa situação em que nenhuma big tech abandona o navegador, isso aconteça?
Opiniões no Lobste.rs
Eu preferia que as pessoas simplesmente fizessem apps nativos. TUI parece uma junção das desvantagens da interface de linha de comando com as de uma GUI de verdade
Todo programa TUI precisa reimplementar a rolagem por conta própria, então mesmo que o terminal suporte rolagem por pixel, programas TUI só oferecem rolagem por linha e cada um funciona de um jeito. O scrollback do senpai é diferente dos outros programas que uso, então vivo me perdendo
Também não existe uma forma de expor ao terminal que a interface é mais do que um único painel de texto, então a seleção de texto quebra com frequência. Dá para fazer isso capturando eventos do mouse, mas isso também é ruim à sua maneira. Em clientes IRC em TUI, eu tinha que apertar um atalho para esconder os painéis laterais aleatórios só para conseguir selecionar texto, o que era um procedimento bem idiota
A restrição de ter que se encaixar numa grade limita bastante as possibilidades de layout e design. Lembro de coisas como estilizar algo para parecer um botão clicável ou menus de contexto. Já reclamei desse problema antes
Acho que o crescimento das TUIs é um resultado lamentável do mau estado dos frameworks tradicionais de GUI. Frameworks de TUI tendem a ser relativamente estáveis, e mesmo usando algo muito antigo isso quase não incomoda. Ainda uso programas em ncurses com frequência, mas é difícil imaginar usar programas em Motif
Já os frameworks de GUI não oferecem tantas opções e exigem muito mais manutenção. Ambientes desktop mudam, e as expectativas em relação a GUI também aumentam. Acho a acessibilidade de TUI realmente ruim, embora eu não tenha certeza absoluta. E as mudanças são constantes: você faz algo em GTK2 e ele entra em descontinuação; atualiza para GTK3 e já mandam ir para GTK4
Vendo de forma cínica, há outros fatores em coisas como Omarchy. Um GUI comum como xfce4-taskmanager é sem graça, mas o TUI btop parece super hacker. As pessoas gostam da estética de terminal (veja /r/unixporn) e parecem dispostas a sacrificar usabilidade por vibe. Basta olhar o btop literalmente aplicando fade na lista de processos
Eu esperava que hoje a barreira de entrada estivesse mais baixa. Num cenário em que a maioria dos desenvolvedores é treinada em linguagens de alto nível, isso parece pouco convincente, e a complexidade do C++ parece me intimidar
[
20:41
]
username1
:
message1
[
20:42
]
username2
:
message2
O Nheko, cliente Matrix, nem deixa selecionar mais de uma linha por vez
Já clientes IRC normalmente oferecem algo assim por padrão
20:41 <username1> message1
20:42 <username2> message2
Às vezes fazem sentido, mas idealmente eu as limitaria a apps pequenos e de uso breve, ou a exceções como edição de texto
Por exemplo, lf, tig, kakoune combinam bem com shell script, então posso reutilizar os mesmos scripts e expandir funcionalidades nos três apps. Como todos rodam no alacritty, também posso criar hyperlinks que funcionam nos três apps e no shell como um todo
Se eu pudesse sonhar, gostaria de um toolkit GUI minimalista monocromático que permitisse uma integração no estilo Emacs ou acme
Não entendo em que sentido TUI seria “fácil de automatizar”. Não é basicamente uma GUI exibida no console?
Este texto deixou passar o principal motivo de a TUI ter “voltado”. A própria ideia é discutível, mas parece verdade que a popularidade recente aumentou com agentes de programação como Claude sendo usados em massa em vibe coding
Desenvolvedores gostam da escolha mais fácil. Criar uma TUI multiplataforma é mais fácil do que criar uma GUI
O mesmo motivo explica a popularidade dos apps web. Era fácil criar apps multiplataforma com ferramentas de navegador, e o Electron cresceu pelo mesmo motivo, só que sem a dor do suporte cross-browser. Criar uma UI responsiva, renderizar uma UI de forma multiplataforma e lidar com entrada do usuário, especialmente com acessibilidade em mente, tudo isso é difícil. Por isso desenvolvedores correm para qualquer coisa que torne isso fácil
Mais recentemente, também houve mudanças que facilitaram ainda mais a criação de TUIs. O suporte multiplataforma a recursos avançados melhorou, surgiram bibliotecas populares que abstraem detalhes complexos, e isso parece ter levado ao renascimento recente das TUIs
Fora isso, acho questionáveis alguns dos outros pontos do texto. Por exemplo, o autor cita consistência como fraqueza de apps Electron, mas TUIs populares também quase não têm consistência além de convenções. Agentes de programação adotaram atalhos parecidos, mas em geral porque todos copiaram a mesma fonte, o Claude. Esses atalhos não se expandem muito bem para fora dos agentes de programação, e a maioria das TUIs que uso tem atalhos e linguagem visual bem diferentes
Também tenho dúvidas sobre “é difícil renderizar uma UI de forma multiplataforma”. É preciso uma camada de compatibilidade e uma implementação para cada plataforma, mas isso não me parece tão mais difícil do que dar suporte a uma única plataforma. Claro, seria diferente se os métodos de renderização das plataformas fossem tão diferentes que dificultassem projetar uma API comum, mas no nível de desenhar pixels na tela isso não parece ser o caso. Fatores como escala precisam ser tratados, mas fora isso deveria ser bem direto, ou então existe SDL
Acho que talvez você esteja falando de fazer a UI parecer “nativa” em todas as plataformas. Aí talvez seja preciso usar o toolkit GUI nativo preferido de cada plataforma, e eles não só são bem diferentes entre si como podem ser muito maiores e menos estáveis do que APIs de renderização de baixo nível. Para esse tipo de coisa, a vida é curta demais. Eu até deixaria espaço para trocar tema de cores ou algum estilo gráfico, mas como configuração do app. Não quero perder tempo lendo as configurações gráficas de cada sistema operacional
Também acho estranho dizer que “entrada do usuário, especialmente acessibilidade, é difícil”. Escutar eventos de teclado e mouse é trivial. Em termos de acessibilidade, é preciso ter navegação por teclado adequada, o que também é importante para a usabilidade geral, além de suporte a atalhos padrão e personalizados, mas no conjunto isso ainda parece muito mais fácil do que o resto
Suporte a leitor de tela pode ser difícil dependendo das APIs da plataforma e das diferenças entre elas, mas isso se parece mais com um problema de renderização do que de entrada
TUI não é tanto um “retorno”, e sim o resultado de termos perdido o conhecimento de programação de GUI nativa e estarmos tentando fazer o melhor possível com as ferramentas que ainda temos. É o resultado de falta de desenvolvimento e investimento consistentes
Tirando algumas exceções luminosas como Qt, a civilização das UIs entrou em colapso e parece que estamos vivendo no pós-apocalipse
Isso me lembra a palestra Preventing the Collapse of Civilization, e agora que a IA escreve muito código, me preocupo que esse colapso de conhecimento se espalhe ainda mais
Dá a sensação de que precisamos de um After Virtue da computação, e talvez a presença online do Blow esteja cumprindo um pouco esse papel. De qualquer forma, sinto falta de uma época em que interfaces de computador mostravam consistência, respeitavam o usuário e recompensavam aprendizado e cuidado
Este texto parece ter pouca substância prática e basicamente só dizer que o autor acha todo o resto ruim
Se for para destacar uma coisa, Emacs é uma ótima plataforma para interfaces de texto, teclado, botões e mídia rica
Provavelmente porque as pessoas começaram a usar bibliotecas de TUI em Go, Rust e agora Zig, em vez de ncurses. Ainda assim, elas resolveram os terríveis problemas de portabilidade que faziam o ncurses ser necessário
Depois disso, as pessoas também começaram a criar novos terminais e a empurrar essa tecnologia adiante. Em parte porque agora dá para fazer isso em Go, Rust ou Zig, e não em C
Se você oferece alternativas melhores, mais divertidas e menos irritantes do que C e C++, é claro que as pessoas vão começar a escrever código mais novo e mais útil
O verdadeiro motivo de a TUI ter voltado é que, em 2026, para distribuir uma GUI assinada e autenticada em cartório você precisa pagar à Apple e, no Windows, também a uma autoridade certificadora
Correção de detalhe: a biblioteca de UI acelerada por GPU do Zed não é a API multiplataforma wgpu, e sim gpui
Não sei se o texto provou bem sua tese, mas como alguém que viveu a era do MS-DOS e sempre gostou de TUI, vou comentar. Se você já usou afl-fuzz, provavelmente entende
Em teoria, TUI deveria ter tido muito mais sucesso no Linux. Havia um público técnico que gostava da estética baseada em texto, e ainda existia a “vantagem” de ambientes GUI toscos e inconsistentes. Houve época em que só fazer a placa de vídeo funcionar direito com o X server já era um problema
Ao mesmo tempo, por décadas os desenvolvedores de software *nix sentiam obrigação de dar suporte até a tipos de terminal antigos e exóticos. Era como se fosse uma catástrofe se a aplicação não renderizasse direito em um DECwriter, e sob esse tipo de restrição era difícil fazer uma boa TUI
Na era do MS-DOS, empresas como Microsoft, Borland e Norton tinham aperfeiçoado interfaces de texto funcionais e responsivas. No Linux, por muito tempo, o “ápice” do design de TUI foi aquele monstro chamado menuconfig, e, se apertar os olhos, talvez até dê para chamar o vim de TUI. Na época em que as pessoas realmente usavam console em modo texto, a única boa TUI de Linux de que me lembro era o gerenciador de arquivos Midnight Commander, inspirado no Norton Commander