Ahora es más fácil construir una UI de terminal

• El equipo de Hatchet presenta un caso en el que desarrolló rápidamente una UI basada en terminal (TUI) con Claude Code
• Usando el stack de Charm (Bubble Tea, Lip Gloss, Huh), lograron un desarrollo basado en componentes al nivel de React y un estilo consistente
• Aunque usa la misma API que la UI web existente, mejora la eficiencia de los desarrolladores con una interfaz centrada en texto y densa en información
• Claude Code ejecutó sesiones de tmux y automatizó las pruebas, desempeñando un papel importante en el desarrollo iterativo y en garantizar la estabilidad
• La TUI de Hatchet, terminada en solo 2 días, se evalúa como un caso que muestra una mejora real de productividad impulsada por LLM

---

Motivación para desarrollar una TUI

• El equipo de Hatchet quería una TUI similar a k9s, y los usuarios la evaluaron como más rápida e intuitiva que la UI web
  • Entre los comentarios de usuarios, hubo opiniones como: “La CLI y la TUI tienen mucho mejor rendimiento”
• Una TUI permite visualizar y ejecutar flujos de trabajo en el mismo entorno que el código, por lo que no hace falta cambiar de pestaña
• Como los principales usuarios de Hatchet son desarrolladores que trabajan dentro del IDE, el objetivo era ofrecer una experiencia de gestión de flujos de trabajo dentro de la terminal

Stack tecnológico

• Se utilizó el stack de Charm, equivalente a un stack de frontend típico (React, Tailwind, etc.)
  • Bibliotecas principales: Bubble Tea, Lip Gloss, Huh
  • El equipo de Charm las mantiene y cuentan con abundante documentación y ejemplos
• Con Lip Gloss y los temas de Huh se aplicó un estilo consistente en toda la TUI
  • El mismo tema también se reutilizó en los comandos de la CLI de Hatchet para ofrecer una experiencia de usuario unificada
• Las personalizaciones fuera de Bubble Tea pueden ser algo difíciles, pero siguen siendo mucho más simples que implementar directamente un motor de renderizado basado en React

Enfoque de pruebas

• Claude Code ejecutó directamente herramientas basadas en terminal para realizar pruebas
  • Se usó tmux capture-pane para capturar la vista renderizada y verificar si la salida era correcta
• Este método fue muy efectivo para automatizar la primera pasada de pruebas, y permitió verificar el renderizado de forma estable incluso cuando aumentó la cantidad de vistas
• Después, se combinaron pruebas manuales y pruebas unitarias para formar un bucle de desarrollo iterativo estable
• Claude Code está optimizado para tareas repetitivas en entornos ASCII, por lo que el ciclo de retroalimentación de pruebas converge rápidamente

Configuración de un entorno de desarrollo eficiente

• Claude Code mejoró la eficiencia del desarrollo al tomar como referencia la implementación frontend existente de Hatchet
  • Se aprovecharon una estructura simple de componentes basada en React y la especificación OpenAPI para establecer límites claros
  • Con un cliente REST API generado automáticamente, fue posible un desarrollo guiado por especificaciones
• La implementación de un renderizador basado en DAG fue la parte más difícil, pero
  • tomando como referencia mermaid-ascii, lograron implementar con éxito un renderizador de gráficos ASCII
  • aunque no es perfecto, sí asegura una función de visualización de DAG utilizable

Resultados y lecciones

• El tiempo total de desarrollo fue de aproximadamente 2 días, mucho más rápido y estable que una refactorización frontend anterior
• Se evalúa como el primer caso en el que el desarrollo con Claude Code mostró una mejora de productividad tangible y no aleatoria
• El equipo de Hatchet planea seguir ampliando gradualmente el desarrollo basado en LLM a funciones fuera de la ruta crítica
• La lección principal es la importancia de bucles de retroalimentación cortos, modularización, diseño guiado por especificaciones y pruebas continuas
• La TUI terminada de Hatchet está disponible públicamente en https://tui.hatchet.run, y actualmente están recopilando comentarios de usuarios

[GN⁺]

Comentarios en Hacker News

• Hay una ironía en que la página hable del rendimiento de las UI de terminal y, aun así, se trabe al hacer scroll incluso en mi Dell XPS de alto rendimiento por efectos complejos como composición de máscaras CSS o gradientes cúbicos
  Según Gemini, esto es un “Scrim o Easing Gradient” que, en vez de lograr un desvanecido suave con 16 color stops, termina recalculando el color de millones de píxeles en cada scroll
  En Firefox la mayoría de las páginas se desplazan con fluidez, así que recomiendan probar también en una laptop hiDPI con iGPU que no sea Mac
  Como referencia, también hay una imagen con el gradiente desactivado — enlace

  • Es cierto. Voy a revisar primero quitar ese efecto para mejorar el rendimiento o eliminarlo por completo. Gracias por el feedback
  • Decir que es “a nivel Commodore 64” ya es demasiado. La C64 de hecho podía hacer scroll suave
  • Comparten una forma de leerlo en Firefox o en otros navegadores sin CSS ni JS. Presentan un script simple que extrae el HTML usando busybox ssl_client y grep, y luego lo abre en Firefox
  • Llamó bastante la atención cuántas veces se menciona Claude Code en la entrada del blog
  • No culpen a mi Commodore 64. Una vez que el programa carga, funciona con mucha suavidad a 50~60Hz

• Me parece un poco triste ese intento de hacer que una TUI se vea como una GUI. Tiene peor accesibilidad y aplana la estructura, así que el usuario no puede usarla fuera de la forma prevista. En cambio, una GUI moderna está conectada estructuralmente con el SO y ofrece mucha más libertad

  • No estoy de acuerdo. En algunos tipos de problemas una TUI es mucho más adecuada. Por ejemplo, los cuadros de diálogo de configuración de paquetes de Debian son bastante más cómodos que texto plano, y además funcionan bien por SSH o consola serial. También son útiles cuando hace falta información visual, como una herramienta que muestre gráficas de CPU
  • Yo uso TUI porque me gusta no tener que instalar otra app de Electron. Es más liviana y no desperdicia recursos metiendo un navegador embebido
  • Siento que las limitaciones de una TUI en realidad mejoran el enfoque del diseñador de UI. Hoy muchas apps esconden los menús y eso es incómodo; la TUI es más clara
  • Me gusta que todo corra dentro de la terminal. Mi flujo de trabajo gira alrededor de multiplexores como tmux, así que cuando aparece una ventana aparte me rompe el ritmo. Esa limitación da simplicidad y consistencia
  • Si ves ejemplos como Emacs, Vim, mc, htop o mutt, queda claro que una TUI puede ser suficientemente poderosa. No todas las UI tienen que ser vistosas

• Hoy en día desarrollar TUI es mucho más fácil que antes. Es gracias a frameworks como BubbleTea, Textualize y Ratatui.
  Con los LLM ahora también se pueden crear estas herramientas rápidamente, y yo mantengo una librería de gráficos TUI llamada NTCharts
  Gracias a la comprensión espacial de Gemini pude resolver bugs, y ahora estoy construyendo con BubbleTea un visor local de conversaciones con LLM
  Enlaces relacionados: issue de NTCharts, proyecto thinkt

• No logro entender esta obsesión con las TUI en las apps de LLM. Si ves Copilot en VS2026, una GUI puede mostrar mucha más información mucho más rápido. Poder hacer clic en los diff en tiempo real es mucho más eficiente

  • Yo uso VSCode, y desde que ahora puedo abrir la barra lateral del agente de IA en una ventana separada, me resulta muchísimo más cómodo que Claude Code. La densidad y precisión de la información visual es mucho mayor que en una TUI
  • La razón es simple. Una TUI es la forma más sencilla de montar rápidamente una UI encima del sistema de archivos. Si lo haces con tecnologías web, necesitas navegador y servidor
  • Las funciones de Claude Code están bien, pero siento que la UI de vista previa de diff con IA de VSCode es mucho mejor. Aunque la nueva versión integrada todavía tiene muchos bugs
  • En realidad esto se parece un poco a un LARP (juego de rol). Es solo un gesto simbólico para parecer un “hacker de verdad”, cuando en la práctica sigue siendo una webapp hecha con React/CSS

• En una época en la que los LLM consumen los recursos de cómputo, esto más bien ha servido como impulso para crear herramientas con stacks livianos.
  Al escribirlo en C, se multiplicó el rendimiento del CPU por miles y se redujo la RAM a la mitad. La TUI es un buen ejemplo de esa eficiencia

  • Aun así, un GUI nativo o frameworks como Flutter podrían rendir mejor que una TUI
  • Queda la duda de cuánto puede compensar la optimización la energía gastada en entrenar LLM
  • Las TUI también ayudan a reducir dependencias. Antes hacían falta 100 paquetes de npm; ahora bastan 200 líneas de JS

• Sigo pensando que Midnight Commander (mc) es una de las mejores TUI que existen. Ofrece casi las mismas funciones que su versión GUI, Double Commander, y además puede correr en remoto.
  Ahora mismo estoy trabajando en un nuevo skin y ojalá entre en la próxima release

  • En lo personal, siento que Far Manager o Dos Navigator son más estables
  • Gracias a los desarrolladores de mc

• Gemini me hizo una TUI para mi proyecto de scraper DHT — imagen
  La primera versión necesitó ajustes por problemas con caracteres CJK, pero en general fue muy impresionante. Gracias a eso pude concentrarme en el algoritmo

  • Me da curiosidad saber qué librería usó
  • Me interesan los proyectos relacionados con DHT. Quisiera saber cómo se aprovecha eso en motores de búsqueda y otros casos
  • Confirman que “DHT” significa Distributed Hash Table. Dicen que es una TUI muy buena

• No veo muy claro en qué una TUI sea mejor que un formulario web o una GUI. En cambio, sí creo que la composición de pipelines de CLI es muy poderosa

  • Algunas instituciones (NSA, CSE, GCHQ, etc.) prohíben las UI web de administración por motivos de seguridad. Por eso nuestro producto se administra mediante TUI por consola local o por SSH. Usamos configuraciones SELinux MAC muy restrictivas
  • Para apps que corren lado a lado con la CLI, una TUI es cómoda. Es fácil dividir ventanas con tmux/zellij, y además hay menos diferencias de UI entre sistemas operativos
  • Las TUI son especialmente útiles en entornos SSH. Incluso funcionan bien en clientes SSH para smartphone
  • Gemini me hizo una TUI para mi proyecto en C#, pero después sugirió que integrar el servidor web Kestrel era mejor. Y tenía razón
  • Las TUI ofrecen buenos keybindings y permiten acceder justo donde se ejecutan los comandos, así que son buenas para tareas rápidas

• Me gusta Claude Code, pero siento que su estructura de TUI basada en React es realmente ineficiente

  • Sobre todo al hacer scroll en textos largos, la degradación del rendimiento es fuerte. Parece que la arquitectura ha sido así desde el principio, y me pregunto por qué es tan difícil corregirlo
  • Si el renderizado ya está hecho en JS, tal vez tenga sentido reutilizar React como motor de reconciliación

• Hice mi propio frontend de prompts basado en Cursor CLI — imagen
  Integré git, diff e historial de chat, y además es fácil acceder desde el teléfono mediante Tailscale.
  Puede reconocer mis reglas y hacer grep en el proyecto, así que la usabilidad es muy alta