Por qué las TUI están de vuelta
(wiki.alcidesfonseca.com)- Las TUI vuelven a llamar la atención por su retroalimentación inmediata, la facilidad para automatizarlas y su capacidad de funcionar entre distintos sistemas operativos; herramientas como Claude y Codex también han tenido un gran éxito en la línea de comandos
- Las GUI nativas de Windows, Linux y macOS aumentan la carga tanto para desarrolladores como para usuarios debido, respectivamente, a estrategias inestables de API, la fragmentación de toolkits y entornos, y una menor coherencia con las guías del pasado
- En las apps de Electron, más que el uso de memoria, los problemas más grandes son la falta de coherencia visual y los huecos en los flujos de trabajo centrados en teclado; además, la integración de menús y atajos también se ha debilitado
- Hubo intentos de crear nuevos stacks de UI, como el esfuerzo de Google con Flutter UI y GPUI de Zed, pero si falta integración con el sistema operativo, un renderizador rápido por sí solo no basta
- En una buena interfaz, la coherencia es clave porque hace que el usuario tenga que pensar menos; los desarrolladores y quienes crean sistemas operativos y toolkits deberían invertir más en teoría de UI y en toolkits accesibles
Por qué las TUI vuelven a llamar la atención
- Omarchy de DHH está compuesto por una mezcla de TUI, web apps y apps nativas estilo gnome, y la TUI se usa por su retroalimentación inmediata y por los “geek points” que da
- Hace unos 10 años ya hubo una tendencia parecida en los editores de código
- Se pasó de editores nativos como BBEdit, Textmate, Notepad++ y Sublime a apps basadas en Electron como Atom, VSCode y sus derivados
- Los usuarios con preferencias más marcadas se fueron a vim o emacs y, a cambio de obtener retroalimentación inmediata y una gran usabilidad, tuvieron que aceptar una curva de aprendizaje muy pronunciada
Por qué se debilitaron las GUI nativas
-
Windows
- Windows no logró construir una estrategia coherente de bibliotecas GUI y repitió el patrón de crear otra API cada vez que una no tenía éxito
- Jeffrey Snover expresó en Microsoft hasn’t had a coherent GUI strategy since Petzold que MFC, OLE, COM y ActiveX extendieron la complejidad por todo el desarrollo en Windows
- Después Microsoft pasó por WinForms, WPF, Silverlight, WinUI y MAUI sin lograr éxito, y muchas apps de escritorio empresariales y de consumo todavía dependen de apps hechas con Electron
- La última época en que Windows estuvo integrado visualmente de forma coherente en su conjunto fue algo cercano a Windows 98 o Windows 2000
- Domenic Denicola sostiene en Windows Native App Development Is a Mess que rehacer el SO y las API de UI cada pocos años tiene un costo alto y que, al combinarse con intentos de sandboxing y de eliminar funciones, cada nueva capa termina dejando huecos donde ya no se puede hacer lo que sí permitían frameworks anteriores
-
Linux
- La falta de coherencia en la UI de Linux se parece más a un resultado de diseño: distintos equipos tuvieron libertad para perseguir objetivos distintos
- GTK y Qt se volvieron los frameworks principales, y aunque ambos apuntaban al desarrollo nativo multiplataforma, su uso más extendido sigue estando sobre todo en Linux
- Las apps de Linux hechas con distintos toolkits pueden verse razonablemente bien unas junto a otras, pero los múltiples frameworks de Windows no logran ese mismo nivel de armonía
- Como hay demasiadas combinaciones de distribuciones, entornos de escritorio y hardware, probarlas es difícil, así que muchas empresas no hacen apps nativas para Linux
- Por lo general, las empresas soportan Linux con Electron o dejan que la comunidad open source lo resuelva por su cuenta cuando existe una API pública
-
macOS
- Las Human Interface Guidelines de Apple eran un estándar tan fuerte que se citaban en clases de interfaces de usuario en todo el mundo
- Xerox PARC y Apple suelen considerarse instituciones clave en la investigación sobre qué hace buena a una interfaz humana
- Últimamente Apple se ha movido en una dirección que rompe con la coherencia de sus guías pasadas
- macOS ignora la ley de Fitts, hace casi imposible redimensionar ventanas, sigue teniendo problemas incluso después de intentar corregirlos y añade íconos a todos los menús
- Ya es difícil ver a macOS como un refugio seguro donde los diseñadores puedan trabajar en paz
Las limitaciones de las apps de Electron
- El problema que más se menciona es el uso de memoria, pero en los últimos 10 años el consumo de memoria ha tendido a bajar
- Los problemas más serios son la falta de coherencia visual y la ausencia de flujos de trabajo verdaderamente centrados en teclado
- Incluso en un entorno con una MacBook Pro de 64 GB de RAM, en el Dock conviven 8 apps nativas y 6 apps de Electron
- Apps nativas: TextMate y utilidades del sistema de macOS
- Apps de Electron: Slack, Discord, Mattermost, VSCode, Cursor y Plexamp
- En apps como Cursor y VSCode, después de pedir una función en el panel del agente, no resulta natural moverse solo con el teclado hacia la lista de agentes del panel lateral o archivar algo desde ahí
- Ese tipo de acciones debería poder hacerse del mismo modo en todas las apps de macOS, pero a veces, incluso cuando existe un atajo, este no aparece en el menú
- En los últimos 10 años, los desarrolladores han tendido a olvidarse de añadir también a los menús las acciones disponibles en la app, y esto se relaciona con una estructura donde la aplicación se implementa como HTML dentro de un sandbox
- Slack maneja mejor estos aspectos que otras apps de Electron, pero no de forma perfecta
Intentos de volver a crear un nuevo stack de UI
- Google quiso crear, junto con Dart, un nuevo sistema operativo y un toolkit de UI para dispositivos nuevos sin la herencia de Android
- Google quería un nuevo toolkit llamado Flutter UI, pero abandonó el proyecto antes de que el producto real saliera al mercado
- Este tipo de intento solo puede tener éxito si existe una posición dominante o una cuota de mercado lo bastante grande
- Zed tomó un camino similar con Rust y creó su propia biblioteca de renderizado por GPU, GPUI, orientada al multiplataforma
- GPUI es rápida, pero su integración con el sistema operativo anfitrión no es suficiente por sí sola, así que el desarrollador tiene que añadir manualmente los bindings que necesita
- Es mejor un renderizador lento bien integrado con el sistema operativo que uno rápido sin esa integración
El vacío que llenan las TUI
- En un contexto que recuerda al declive de Apple Automator, las TUI vuelven a ganar importancia como interfaces automatizables
- Las TUI también son relativamente fáciles de ejecutar en remoto y no dependen del problemático X forwarding
- Cuando los toolkits de UI nativa fallan, se vuelve a lo básico, y como resultado la TUI reaparece como opción
- Claude y Codex han tenido un gran éxito en la línea de comandos, y los usuarios pueden concentrarse más en la interacción en sí que en el sistema operativo que tienen alrededor
- Mediante TUI se puede trabajar con código y apps en máquinas en la nube o conectarse en remoto desde un iPad a una máquina con GPU
- La TUI está llenando el vacío que dejaron Apple y Microsoft en un entorno donde cada aplicación se ve diferente a las demás
- Las apariencias distintas pueden servir para el arte o los videojuegos, pero no encajan con el objetivo de que la interfaz se haga a un lado para que el usuario pueda hacer su trabajo
Hacia dónde habría que avanzar
- En Bring Back Idiomatic Design, John Loeber plantea que hasta una casilla de verificación es una interfaz para interactuar con el sistema, y que una buena interfaz hace que el usuario tenga que pensar menos
- Como los usuarios interactúan con muchas cosas, necesitan interfaces homogéneas que les den una experiencia consistente
- Si Command+C es el atajo para copiar, debería funcionar en todas partes; tener que recordar que en ciertos casos hay que usar CTRL+Shift+C o clic derecho → copiar es incómodo
- Todo desarrollador debería aprender no solo software, sino también la teoría que hace mejores las interfaces de usuario en general
- Hay que dejar de tratar el diseño de usuario como si fuera una soft skill poco importante dentro del plan de estudios de ingeniería de software
- En cualquier curso, si no se entiende la UI, el proyecto debería considerarse fallido; en los cursos de HCI, la meta debería ser una UI perfecta
- La mayor parte del esfuerzo para construir una buena UI está en entender las necesidades, mientras que la programación en sí ya se está automatizando
- Quienes crean sistemas operativos y toolkits deberían impulsar inversiones para construir toolkits accesibles que los desarrolladores realmente quieran usar y reducir las barreras de entrada
- No se está diciendo que el soporte multiplataforma deba imponerse siempre, pero contar al menos con una solución así podría ayudar a reducir la dependencia de Electron y de las TUI
2 comentarios
Yo también lo creo, pero me parece que el mundo del desarrollo es excesivamente sensible a las modas. Las TUI simplemente están siendo impulsadas por empresas que no tienen la capacidad o la voluntad de crear una GUI como se debe; no sé cuánta gente está usando realmente las TUI.
Opiniones en Lobste.rs
Ojalá la gente hiciera mejor apps nativas. Las TUI parecen combinar las desventajas de la interfaz de línea de comandos y de una GUI de verdad
Todos los programas TUI tienen que reimplementar el scroll por su cuenta, así que aunque la terminal soporte desplazamiento por píxeles, los programas TUI solo soportan scroll por líneas y cada uno funciona distinto. El scrollback de senpai funciona diferente a otros programas que uso y termino perdiéndome a cada rato
Tampoco hay forma de exponerle a la terminal que la interfaz es más que un solo panel de texto, así que la selección de texto se rompe seguido. Se puede si interceptas eventos del mouse, pero eso también tiene sus propios problemas. En un cliente IRC TUI tenía que apretar un atajo para ocultar los paneles laterales solo para poder seleccionar texto, y era un procedimiento bastante tonto
La restricción de tener que ajustarse a una cuadrícula limita muchísimo las posibilidades de layout y diseño. Me hace pensar en esos intentos de estilizar cosas para que parezcan botones clickeables, o en menús contextuales y similares. Incluso me quejé de este problema hace tiempo
Veo el aumento de las TUI como una consecuencia desafortunada del mal estado de los frameworks GUI tradicionales. Los frameworks TUI suelen ser relativamente estables, y aunque uses uno muy viejo no molesta demasiado. Los programas con ncurses todavía se usan mucho, pero cuesta imaginar a alguien usando programas con Motif
En cambio, los frameworks GUI tienen pocas opciones y requieren mucho más mantenimiento. Los entornos de escritorio cambian, y también crecen las expectativas sobre las GUI. Me parece que la accesibilidad en TUI es realmente mala, aunque no lo afirmo con total seguridad. Además todo cambia mucho: haces algo con GTK2 y queda obsoleto, lo subes a GTK3 y luego te dicen que te pases a GTK4
Viéndolo con cinismo, en cosas como Omarchy también hay otros factores. Un GUI normal como xfce4-taskmanager es aburrido, pero una TUI como btop se ve súper hacker. A la gente le gusta la estética de la terminal (ver /r/unixporn), y parece dispuesta a sacrificar usabilidad por la vibra. Basta ver cómo btop literalmente hace fade out de la lista de procesos
Esperaba que hoy la barrera de entrada fuera más baja. En un mundo donde la mayoría de los desarrolladores se forman con lenguajes de alto nivel, no parece muy convincente, y creo que la complejidad de C++ me intimida
[
20:41
]
username1
:
message1
[
20:42
]
username2
:
message2
El cliente Matrix Nheko ni siquiera deja seleccionar más de una línea a la vez
En cambio, los clientes IRC normalmente te dan algo así
20:41 <username1> message1
20:42 <username2> message2
A veces tienen sentido, pero idealmente deberían usarse solo para apps pequeñas y de uso breve, o en excepciones como la edición de texto
Por ejemplo, lf, tig, kakoune encajan muy bien con scripts de shell, así que puedes reutilizar los mismos scripts y extender funcionalidad en las tres apps. Como todas corren dentro de alacritty, también puedo crear hipervínculos que funcionan en las tres y en el shell en general
Si pudiera pedir un deseo, me gustaría un toolkit GUI minimalista monocromático que permitiera una integración al estilo Emacs o acme
No entiendo cómo se supone que una TUI sea “fácil de automatizar”. ¿No es básicamente una GUI mostrada en la consola?
Este artículo omitió la razón clave por la que las TUI “volvieron”. Incluso dudo de esa premisa, pero sí parece cierto que su popularidad reciente subió por la cantidad de vibe coding hecho con agentes de programación como Claude
A los desarrolladores les gustan las opciones fáciles. Es más fácil hacer una TUI multiplataforma que hacer una GUI
La misma razón explica por qué se hicieron populares las apps web. Era fácil hacer apps multiplataforma con herramientas del navegador, y el auge de Electron va por la misma línea, quitando el peso del soporte cross-browser. Hacer una UI responsiva, renderizar una UI de forma multiplataforma y manejar la entrada del usuario, sobre todo pensando en accesibilidad, son cosas difíciles. Por eso los desarrolladores se lanzan de inmediato a cualquier cosa que haga eso más fácil
Últimamente también hubo cambios que facilitaron crear TUI. Mejoró el soporte multiplataforma para funciones avanzadas, aparecieron librerías populares que abstraen detalles complejos, y eso parece haber llevado al reciente renacimiento de las TUI
Fuera de eso, varios puntos del artículo me parecen dudosos. Por ejemplo, el autor menciona la consistencia como una debilidad de las apps Electron, pero en las TUI populares casi no hay consistencia más allá de algunas convenciones. Los agentes de programación adoptaron atajos parecidos, pero en gran parte porque casi todos copiaron la misma fuente, Claude. Esos atajos no se extienden muy bien fuera de los agentes de programación, y la mayoría de las TUI que uso tienen atajos y lenguaje visual bastante distintos
También me genera dudas eso de que “renderizar una UI de forma multiplataforma es difícil”. Sí, necesitas una capa de compatibilidad y una implementación por plataforma, pero no parece mucho más difícil que soportar una sola plataforma. Claro, sería distinto si los métodos de renderizado entre plataformas fueran tan diferentes que costara diseñar una API común, pero a nivel de poner píxeles en pantalla no creo que sea así. Hay cosas como el escalado que sí hay que resolver, pero más allá de eso debería ser bastante directo, y si no, ahí está SDL
Supongo que en realidad se refería a hacer que la UI “se vea nativa” en todas las plataformas. Eso sí podría obligarte a usar el toolkit GUI nativo preferido de cada plataforma, y esos pueden ser muy distintos entre sí, además de más grandes y menos estables que una API de renderizado de bajo nivel. Para eso la vida es demasiado corta. Yo quizá dejaría margen para cambiar algunos temas de color o estilos gráficos, pero como configuración de la app. No quiero perder tiempo leyendo la configuración gráfica de cada sistema operativo
También se me hace raro decir que “manejar la entrada del usuario, especialmente la accesibilidad, es difícil”. Escuchar eventos de teclado y mouse es trivial. En accesibilidad sí necesitas navegación por teclado bien resuelta, que también es importante para la usabilidad general, además de soporte para atajos estándar y personalizados, pero en conjunto eso me parece mucho más fácil que el resto
El soporte para lectores de pantalla sí puede ser difícil dependiendo de la API de cada plataforma y de las diferencias entre ellas, pero eso se parece más a un problema de renderizado que de entrada
Más que un “regreso”, las TUI se parecen a gente haciendo lo mejor que puede con las herramientas que tiene porque se perdió el conocimiento de cómo programar GUI nativas. Es el resultado de la falta de desarrollo e inversión sostenidos
Salvo algunas pocas excepciones luminosas como Qt, la civilización de las UI colapsó y da la impresión de que vivimos en la posapocalipsis
Me suena a la charla Preventing the Collapse of Civilization, y ahora que la IA está escribiendo mucho código me preocupa que ese colapso del conocimiento se propague todavía más
Da la impresión de que hace falta un After Virtue de la informática, y quizá la presencia online de Blow esté cumpliendo ese rol. En cualquier caso, extraño la época de las interfaces de computadora que mostraban consistencia, respetaban al usuario y recompensaban el aprendizaje y el cuidado
Este artículo no parece tener mucho contenido real; más bien solo dice que al autor le parece que todo lo demás es pésimo
Si hay algo que sí diría es que Emacs es una plataforma excelente para interfaces de texto, teclado, botones y medios enriquecidos
Probablemente porque la gente empezó a usar librerías TUI en Go, Rust y ahora Zig, en vez de ncurses. Aun así, resolvieron los horribles problemas de portabilidad para los que ncurses era necesario
Después la gente empezó a hacer terminales nuevas y a empujar también esa tecnología. En parte porque ahora se puede hacer en Go, Rust o Zig en vez de C
Si les das a las personas opciones buenas, más divertidas y menos irritantes que C y C++, obviamente van a empezar a escribir código más nuevo y más útil
La verdadera razón por la que las TUI volvieron es que en 2026, para distribuir una GUI firmada y notarizada, tienes que pagarle a Apple, y para Windows también tienes que pagarle a una autoridad certificadora
Corrección menor: la librería de UI acelerada por GPU de Zed no es la API multiplataforma wgpu, sino gpui
No sé si el artículo demostró bien su tesis, pero como alguien que vivió la era de MS-DOS y siempre ha disfrutado las TUI, me meto a opinar. Si has usado afl-fuzz, probablemente lo entiendas
En teoría, las TUI deberían haber tenido mucho más éxito en Linux. Había una base de usuarios técnicos a la que le gustaba la estética basada en texto, y también existía la “ventaja” de tener entornos GUI toscos e inconsistentes. Incluso hubo una época en la que ya era un problema lograr que la tarjeta de video funcionara bien con el servidor X
Al mismo tiempo, durante décadas los desarrolladores de software *nix sintieron la obligación moral de soportar hasta tipos de terminal viejos y exóticos. Como si fuera una tragedia que una aplicación no renderizara bien en una DECwriter, y bajo esas limitaciones era difícil hacer buenas TUI
En la era de MS-DOS, empresas como Microsoft, Borland y Norton perfeccionaron interfaces funcionales, rápidas y basadas en texto. En Linux, durante mucho tiempo el “punto más alto” del diseño TUI fue ese monstruo llamado menuconfig, y si entrecierras los ojos hasta podrías llamar TUI a vim. En la época en que la gente realmente usaba consolas en modo texto, la única buena TUI de Linux que recuerdo era el administrador de archivos Midnight Commander, inspirado en Norton Commander