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
4 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 de Hacker News
Si uno ve solo los números, la verdadera razón de la popularidad de las TUI es Claude Code; todo lo demás me parece casi ruido de fondo en comparación.
La primera vez que quise crear una TUI fue por la idea de entregar aplicaciones a través de SSH. Una app por SSH se parece al navegador en que no requiere instalación local.
Una gran razón por la que me divierte tanto jugar con https://pico.sh es que desplegar una TUI no requiere absolutamente ninguna intervención del usuario.
Supongo que se debe al deseo de alejarse de las UI pesadas basadas en navegador y a la curiosidad por poner a prueba los límites del renderizado en terminal.
En vez de construir sistemas nuevos con tecnología nueva e interesante, estamos haciendo emuladores de máquina de escribir con aceleración por GPU. Es una forma extraña de mezclar nostalgia con ceguera técnica.
Se puede pasar cualquier protocolo por encima de SSH. Preferiría que avanzáramos hacia dibujar sobre una pantalla remota de mapa de bits.
X Window no estaba brillantemente diseñado, pero tenía transparencia de red, y el devdraw de Plan 9 era un motor de renderizado donde los programas gráficos remotos subían sus recursos y luego enviaban comandos RPC para dibujar líneas.
Lo realmente difícil de vim es solo que, para volver al modo comando, que es el núcleo de un editor modal, hay que estirar los dedos hasta Escape.
El flujo ideal es editar rápido y volver de inmediato al modo comando, y vale la pena señalar que usar Escape es un residuo histórico.
Por eso basta con remapear globalmente CapsLock a Escape. En Linux y macOS se puede hacer solo con la configuración de la GUI, y en Windows también se termina en un minuto creando o modificando una clave del registro.
Fuera de eso, puedes aprender lo básico con vim-tutor y buscar lo demás cuando te encuentres tareas que tomen mucho tiempo, así que no sé bien dónde estaría la famosa curva de aprendizaje. El problema es que uno se acostumbra demasiado rápido a la edición modal y luego los entornos que no la tienen parecen de la Edad de Piedra.
Hoy en día creo que la razón real por la que vim necesita hjkl es que la distribución del teclado es mala para las flechas. Las máquinas de escribir no tenían flechas, pero en una computadora las flechas son fundamentales.
Tampoco hace falta que la barra espaciadora sea tan grande ni que ambos pulgares tengan que usarla. Sería mucho mejor mover un pequeño bloque de flechas a alguna parte a la izquierda o derecha de la barra espaciadora.
El hack de hjkl solo funciona en editores para hackers, pero en el software general también hay que usar mucho las flechas, y la distribución actual es muy mala para las manos. Me empezó a salir inflamación por tratar de pulsar las flechas con el pulgar sin mover toda la mano.
Obliga a levantar la mano, salir de la posición base y volver a colocarla, lo que reduce puntos de RSI que de otro modo se irían acumulando en silencio.
Por la misma razón también uso bastante las teclas de flecha con la otra mano. Claro, también uso hjkl con bastante frecuencia.
https://github.com/microsoft/PowerToys
jj.Además,
Ctrl + [es Esc en terminal/ASCII estándar, así que puede ser un poco más cómodo que estirar la mano hasta Esc.Lo que parece una moda de las TUI son en realidad las cenizas que quedan tras el colapso del interés propio de los proveedores de sistemas operativos.
No hay ni una sola buena UI de propósito general. El navegador es lo menos malo y ha tenido bastante éxito, pero por el sandbox no sirve bien, o genera mucha fricción, para tareas que necesitan acceso a archivos locales o a la red. Y además tiene un overhead ridículo para ejecutar cosas simples.
El acceso remoto está todavía peor. Te encuentras con problemas como si puedes acceder desde una Mac a una app que corre en un host Windows, o si eso se puede reenviar por una conexión tunelizada.
La TUI es un protocolo de propósito general simple que hace lo necesario y además es remota por naturaleza. Lo que usas localmente también funciona de forma natural sobre una conexión SSH.
También es una gran mentada de madre a los proveedores de sistemas operativos que pensaron que la estrategia ganadora era volver todo incompatible o encerrarte en su ecosistema.
Notcurses y Ratatui han ayudado mucho a ncurses.
Windows 11 es un gran ejemplo, y todo ese circo realmente no hace falta.
Ojalá las TUI no volvieran. Cualquier día elegiría una interfaz web antes que una TUI.
No hace falta instalar fuentes demasiado ingeniosas, ni tocar la configuración de la terminal para que todo se muestre bien, ni adivinar los atajos de navegación que al autor le parecieron los mejores.
También tienes edición de texto real con navegación estándar del sistema operativo, y mejor integración con el gestor de contraseñas, expansores de texto y demás.
Vivo dentro de la CLI y abro la terminal con un atajo, pero la tecnología avanzó muchísimo desde la época en que la terminal era la única opción, y hoy hay muchas formas mejores de construir una UI.
Toda esta moda de las TUI me parece simplemente una tendencia pasajera.
Porque nadie invierte en desarrollo de UI nativas. Electron demuestra que las empresas adoptarían una pila GUI fácil de usar si existiera.
Si es una app grande, el tiempo dedicado al empaquetado y despliegue pesa poco dentro del total y el tamaño del archivo tampoco importa tanto, pero con apps pequeñas no pasa eso.
En Windows una app así es fácil: un binario pequeño abre un formulario, se ejecuta con doble clic y no necesita instalación.
En Linux no puedes asumir que GTK o Qt estén instalados, así que para volverla autónoma en la práctica tienes que mandar casi todo el sistema operativo con ella. Entonces el tamaño del archivo se dispara.
Python también es problemático porque el usuario de Windows o tiene que tener Python o hay que enviar el intérprete junto con la app.
La única alternativa medio viable es algo como Java, con un solo archivo
.jarque corre en cualquier sistema, pero Oracle cambió la licencia y JavaFX ya no viene incluido en Java. Swing todavía sí.Solo quiero mostrar una barra de menú con atajos de teclado; no entiendo por qué no existe algo como una VM de barra de menú que permita acceder a la barra de menú en todos los sistemas operativos.
Enviar un navegador entero con Electron es una tontería. Debería funcionar como una plataforma al estilo de la versión de escritorio de Flash, donde el usuario instala eso y todas las apps lo usan.
Capaz que distribuir un juego de DOS es más fácil que distribuir una app de escritorio, porque quien quiera correr juegos de DOS probablemente ya tendrá instalado un emulador de DOS.
Lo que hace falta es un framework fácil de usar, multiplataforma, open source y, si es posible, utilizable desde el lenguaje de programación que elijas.
El problema más grande es la mano de obra. Hay muchísima gente que sabe desarrollo web, así que quieres aprovechar a esa misma gente también en escritorio, y eso es mucho más fácil si el escritorio usa JavaScript, como en Electron.
No termino de entender esas UI de terminal que intentan recrear funciones tipo GUI. ¿No se supone que las interfaces de computadora deberían mejorar?
Ya no estamos obligados a limitarnos a una cuadrícula de caracteres fingiendo dibujar líneas y formas. Ni siquiera puedes mostrar imágenes sin terminales no estándar como Kitty o iTerm.
Da pena que no exista un gran sistema de UI transmitida multiplataforma. La web es bastante buena a su manera, pero para este propósito claramente podría existir algo mejor. Flutter está bien, pero le falta esa naturaleza on-demand y está demasiado atado a Dart.
La gente quiere GUI, pero al final tiene que desviarse hacia algo parecido a una GUI dentro de una TUI.
Quiere algo portable, que se pueda ejecutar en remoto, que sea más seguro sin exponer sockets y que no obligue a levantar un escritorio completo.
Las ventanas rootless están prácticamente muertas, y lo único que queda es la interfaz web con todos sus problemas, o una TUI que funciona con la conexión SSH que todo el mundo ya tiene.
Antes podías improvisar algo con Tcl/Tk y abrir una ventana por X Window, pero hoy no es fácil y ya nadie usa X remoto.
El mínimo común denominador es SSH, y solo sobrevive lo que encaja ahí.
Varias de las terminales mencionadas como no compatibles también están basadas en GNOME VTE, y ese soporte está en desarrollo; si ves el bug tracker, parece que ya casi está listo.
Eso también incluye a xterm, que en X11 es probablemente lo más parecido a la terminal estándar.
[0] https://www.arewesixelyet.com/
Tampoco es que haya un toolkit GUI sólido y confiable; todos están llenos de bugs y peculiaridades diferentes.
Dicen que Flutter está bien, pero para eso hay que ignorar que el propio proceso de compilar apps con Flutter es una pesadilla. Flutter tampoco se siente diseñado para que compile cualquiera; en la práctica son las distribuciones las que esconden ese problema.
Y una UI basada en web tampoco tiene por qué ser pesada. Hacker News mismo demuestra que no necesariamente es así.
Incluso para alguien que siempre tiene una terminal abierta, automatiza la vida con scripts de Bash y usa VIM/TMUX, la mayoría de las TUI están dos pasos detrás de una buena GUI.
Navegación caprichosa y atajos raros, copiar y pegar roto, y poca integración con el entorno son ejemplos claros.
El problema central es que no existe una plataforma GUI multiplataforma decente que esté bien integrada con los lenguajes de programación o que sea parte de la biblioteca estándar.
A Swing le falta acceso a elementos nativos del navegador; a Tk le faltan componentes de navegador y arrastrar y soltar; wxWidgets tiene una comunidad pequeña y sus bindings da la impresión de que han tenido que resucitarse más de una vez.
Qt siempre corre el riesgo de arruinarse cuando quieran exprimir más dinero; tampoco me parece que KDE sea tan importante, y dudo que la comunidad de KDE pueda sostener un fork a largo plazo.
Lo que queda son Electron o variantes donde montas JavaScript/CSS encima de un componente de navegador con callbacks a un servidor local, y más allá del gran overhead de memoria y runtime incluso en apps triviales, el propio modelo de programación es malo.
Para hacer un toolkit GUI multiplataforma de verdad hacen falta mucho dinero y mucha gente para usabilidad, accesibilidad, diseño, documentación y pruebas. La comunidad open source no lo ha logrado, GTK se volvió de facto solo para Linux y no existe un candidato moderno que reemplace a Qt o Swing.
Las TUI no son la solución al problema de fondo, pero viendo las alternativas se entiende a los desarrolladores que las eligen para UI multiplataforma. Diría que como el 80% de las necesidades de GUI se podrían cubrir con un toolkit GUI que tuviera un renderizador TUI.
Así puedes proporcionar una API y ABI estables, y hacer bindings desde muchos otros lenguajes sin rodeos complejos. En especial importa más en lenguajes compilados.
Puede que enlazar Qt con Python sea fácil, pero si quieres conectarlo con un lenguaje como Free Pascal necesitas una biblioteca intermedia en C++ que exponga una API en C, y la app además tiene que distribuir también esa biblioteca.
Por desgracia, la mayoría de los toolkits GUI están escritos en C++ u otros lenguajes en vez de C, así que si no usas el lenguaje favorito del desarrollador, terminan siendo dolorosos de usar. De los mainstream, casi el único escrito en C es GTK, pero GTK casi no se preocupa por una compatibilidad hacia atrás adecuada.
Uno podría pensar que da igual en qué lenguaje esté escrita una biblioteca si solo expone una API en C, pero si no es algo ampliamente distribuido, quizá quieras enlazar estáticamente. Y ahí, fuera de C/C++, eso se vuelve un problema.
Por ejemplo, intenté hacer un backend FLTK para Lazarus[0]. FLTK es una biblioteca en C++ y recomienda enlazado estático, así que parecía que permitiría crear binarios GUI autónomos.
Pero primero había que hacer un wrapper en C, y enlazar estáticamente una biblioteca en C++ desde un lenguaje que no fuera C/C++ sin las flags mágicas que g++ le pasa al linker en Linux era doloroso; en Windows, o al menos en msys2, era imposible, así que lo abandoné.
[0] https://i.imgur.com/W6XbLkr.png
En macOS y Windows se parece muchísimo al aspecto nativo, y además es mucho más fácil de programar que Qt. Tanto como usuario como, a veces, como programador, es mi opción favorita para GUI multiplataforma.
En cambio, de verdad odio como usuario la combinación de Electron o un componente de navegador con JavaScript/CSS y callbacks a un servidor local. Incluso si tuviera que renunciar a funciones y volver a la línea de comandos, preferiría evitar esas apps.
Ni siquiera soportan atajos de teclado estándar, se ven raras y pegadas con cinta, y se traban en lugares inesperados.
Hay frameworks TUI que casi han llegado a ese nivel. Está bien que puedan usarse por SSH y similares sin esfuerzo extra, pero siento que están resolviendo el problema equivocado.
Más que hacer que todo se vea o funcione como un IDE, preferiría CLI más enfocadas y componibles, junto con algo tipo tmux cuya gestión de ventanas y persistencia sea menos terrible.
Si haces un REPL simple con readline, obtienes un comportamiento estándar y predecible.
Aun así, sí me gusta que esta tendencia esté empujando mejoras en los emuladores de terminal.
Las TUI que he visto parecen depender en su mayoría de NPM.
Se siente raro, como si los agentes ni siquiera tuvieran tiempo de reescribirse a sí mismos en algo que no sea un incendio de llantas de seguridad.
Toda esta ola de que los agentes se van a adueñar de algo me hace pensar que al final viene de gente startup que vive de basura-conversión-basura y a la que no le preocupa mucho el resultado mientras no sea demasiado lento.
Por ejemplo, OpenCode todavía no logra bien ni lo básico de conservar todos los logs de mensajes y enviarlos al endpoint SSE en el mismo orden para obtener la siguiente respuesta; incluso con el podado de contexto desactivado sigue habiendo muchos misses en la caché de prompts.
La experiencia de desarrollo es excelente y no hace falta npm.
curl | bash.Es raro que se permita a los desarrolladores de software diseñar interfaces de usuario.
Parecen incapaces de crear interfaces de usuario no textuales. Es como si dejaras a un plomero diseñar una casa y él inclinara todos los pisos hacia abajo para que las tuberías fueran más fáciles de pasar.
Si hay que mover y redimensionar varias ventanas, hacen una ventana de texto; si hay que elegir opciones rápido, hacen un cuadro de texto; si hay que escribir rápido documentos con estilo y formato, te hacen escribir todavía más texto para aplicar formato.
Y aun así luego ni siquiera crean una app donde puedas ver fácilmente ese texto ya formateado.
Se puede hacer, y si no te gusta, no lo uses.
Se ven bonitos, pero son casi inútiles para cosas complejas más allá del desarrollo de apps con ese estilo o de algo como un gestor de archivos.
Las TUI son buenas para la gente que vive dentro de la terminal.
No hay distracciones de contenido visual, son extremadamente eficientes con teclado y ahora además la IA puede producirlas rápido. Antes sí era realmente doloroso.
Como creció la audiencia de las TUI, también se volvieron más comunes.
Y dentro de 80 columnas de texto tampoco hay mucho que un product manager pueda simplificar.
¿No está mal que, en una situación donde ninguna big tech abandona el navegador, se vuelva a apostar por eso?
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