Por que a TUI está voltando

• 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 de CTRL+Shift+C ou 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
  • Nielsen
  • Norman
  • Johnson
• É 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

[colus001]

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.

[GN⁺]

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

  • Depois de muito tempo com desenvolvimento web, eu queria experimentar desenvolvimento de aplicações nativas. Fui olhar como criar apps para GNOME e fiquei bem desanimado por ser tão centrado em C++
    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
  • Meio de lado, mas não entendo por que tantos clientes de chat deixam o histórico todo bagunçado quando você copia e cola. No Discord, por exemplo, fica assim
    [
    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
  • Eu gosto de interfaces de linha de comando, mas também não sou fã de TUI. Elas têm seu uso, mas na prática são mais parecidas com uma GUI áspera e feia, e muitas vezes desperdiçam espaço no terminal
    À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
  • Acho TUI meio fraca, mas comparada com toolkits de UI como gtk ainda é a opção menos pior. Os apps TUI de que gosto são extensíveis, rápidos e se integram bem à linha de comando do Linux
    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
  • Em geral concordo, mas vale notar que o Tk segue firme, discretamente, e ainda hoje é útil. gitk é um exemplo

• Não entendo em que sentido TUI seria “fácil de automatizar”. Não é basicamente uma GUI exibida no console?

  • Muitas TUIs oferecem flags que funcionam como uma linguagem de script ao abrir o programa. Além disso, para um LLM é mais fácil e barato interagir com uma interface baseada em texto do que com uma GUI nativa de verdade ou um app Electron com jeito de JavaScript

• 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

  • Não entendo muito bem o que quer dizer “é difícil criar uma UI responsiva”. Isso soa como coisa da web; algumas ideias da web até podem se aplicar, mas para GUI nativa parece meio fora do assunto. Você quis dizer só “fazer uma boa UI” ou “fazer um toolkit de UI”?
    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

  • Sempre apareço quando esse assunto surge no lobste.rs, então achei que devia aparecer aqui também. Todos os “impérios” de GUI estão desmoronando diante dos nossos olhos. Windows, macOS, GTK, produtos da Mozilla, todos
    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

  • Um binário TUI nativo não tem o mesmo problema?

• 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