There are other great examples of TUIs that i've seen around the web:
https://github.com/ratatui/awesome-ratatui
https://terminaltrove.com/explore/
https://github.com/rothgar/awesome-tuis
But I think we will swing back to using GUIs when we find a performant way of making them, I don't know what it is yet but surely someone is working on this.
TUIs look good to look at though!
- TUI libraries like Lipgloss and Bubbletea really allow users to build a rich experience nowadays. Really anything from https://charm.land is well-polished and a joy to use.
- Kitty image format works great and allows for Avatars, image previews, etc, which helps immensely make slk feel like a Slack client and not an IRC client.
I might be missing something here, but wouldn't any UI toolkit that doesn't live within a WebView work?
I like this new TUI renaissance as well, but if you wanna see what a symbiotic relationship between GUIs x TUIs could look like you need to see what Emacs does with Orgmode and the whole Org ecosystem of org-agenda, org-roam, etc. Lot's of these TUIs from the awesome are somewhat already inside Emacs.
https://orgmode.org/ https://orgmode.org/manual/Agenda-Views.html
The only software that is as fast as TUI is the Zed IDE. Apparently they use Rust + their own built GUI toolkit with GPU rendering.
And apparently it's tightly coupled with Zed.
- frameworks for tui development, including react-like DOM shit
- further ad-hoc specs building on top of ANSI escape codes for finer control
- maybe a scripting language
Display technology has seen so much progress in the past decades. Apple marketing has taught us about "Retina" displays with pixels so small that you can't tell them apart without a microscope. We get these very rich and colorful desktop environments but we actively decide to not use any of that.
Now, I get that a TUI can look incredibly crisp with proper text rendering, kerning, ligatures, nerd fonts and so on, but still with all that, at the end of the day we still have a thingamajig that implements a VT100. It is a strict subset of what could potentially be drawn with a proper GUI framework.
I understand that TUIs can run over SSH channels, can be juggled with Zellij/tmux/mprocs -- as such they are composable in the sense that they can be used in a way the author(s) didn't think of. It's been a while since I've done any of that personally, and I for one think it's a bit of a cop-out that the Claude Code integration in PyCharm is just the TUI [1] inside a terminal emulator inside my IDE when it could be so much more, just to provide one example.
The article shows off an strace TUI, and it's not like I can't see the benefits of making strace output more browsable. What I don't understand is why that must happen inside a terminal window where (for instance) all text must have the same font and size.
So what is the appeal? I'm asking in good faith. Is it because the perceived alternative is another run-off-the-mill Electron RAM guzzler, because there aren't any _good_ GUI widget frameworks? Is it the multi-platform aspect?
If all we work in are these super-lean TUIs maybe we don't even need so powerful computers or such high-DPI displays anymore?
I'm genuinely puzzled, but interested to know how TUIs appeal to other people.
1) which, I understand, is itself a React app with a console renderer!
The article shows off an strace TUI, and it's not like I can't see the benefits of making strace output more browsable. What I don't understand is why that must happen inside a terminal window where (for instance) all text must have the same font and size.
Yes, there are things like https://github.com/ocornut/imgui, and some (especially open source) applications try and muddle a long with Qt or GTK, but many (most?) serious professional or power user applications have built their own GUI frameworks or at least custom controls to deal with this.
Whatever route you take, as a dev it's painful, especially for someone who remembers adding a couple of libraries to a Delphi project back in the Office 2000s era and getting full docking, configurable toolbars, etc. with little to no work.
So the easy fallback (especially with the recent proliferation of libraries) is TUI and CLI applications with the layout/docking and tabs provided by the terminal emulator itself or one of tmux/zellij/etc.
I've been thinking on and off for a few years now about the idea of a "graphical terminal", sitting somewhere between a GUI toolkit and a terminal emulator and a full blown OS for building inter-composable apps and tools and components that could replace TUI based workflows/apps/layouts. I have a vision of every "pro" app just being a different curation and configuration of underlying components rather than actually separate software.
Are you thinking about emacs?
- Optimizing for fast, keyboard-only usage
- Allowing me to customize the presentation according to my preferences
- Not having to leave my terminal, where I spend most of my time (I do realize this is something of a chicken-and-egg situation)
It is hard to remove the rise of agentic flows and LLMs generally from this discussion. The fact that LLMs understand text in a first-class way and have had more time to get good at them, means that they can iterate and build apps and features that might bog down a model in the context of a GUI app and all of the additional context required for the larger framework and deployment and testing story.
These attributes and the current environment with LLMs mean that it's really easy to build ephemeral UIs that serve a purpose right now, and then consider productionizing or generalizing at a later date. If you decide to do this, you have the really high fidelity tests that make it easier.
I do this all the time.
One of my favourite applications is a tool called "autoexpect" and I use it every time I try a new program.
What it does is this: I run a program in it's virtual terminal, and it writes a TCL script that does what I did, and puts little regex tests in for the output of that program for me. I can then edit that program (or not: sometimes the first output is fine).
Once upon a time I used to use a program called DESQview: It had a "learn" feature that allowed you to record and playback even DOS programs, so it was very easy to pick up autoexpect.
DESQview/X was their X11 server, and it also had the "learn" feature, but unless the application could be driven entirely by the keyboard, it didn't work; most similar applications I've seen over the decades since need such care for reliable "scripts".
Yes sometimes you also have the possibility of using the GUI accessibility framework to "script" the app. This is barely ok if it works, but most GUIs that I want to script were designed so that would not work at all, and it is coding that requires me work with the app instead of asking a domain expert for a recording.
autoexpect on the other hand is just text, easy to read and modify, and easy to send by email. It is hard to make a terminal application hostile to autoexpect without a great deal of work that (in the text based environment) can usually be undone just by using tmux and mosh on loopback.
> What I don't understand is why that must happen inside a terminal window where (for instance) all text must have the same font and size.
Modern (as in, since the 1980s) terminals are very capable of multiple fonts and font-sizes. I usually use a non-proportional font for coding myself.
Is that really true? Can I, in one terminal window, have prose with a serif font and code with a monospaced font at the same time? If I hover over something with my mouse, can I have a TUI tooltip at a smaller font size?
There once was a program called https://en.wikipedia.org/wiki/ManaGeR which appears at first blush to be some kind of X11-competitor, except it was using the VT330's regular terminal capabilities to do those fancy pixel-patterns and fonts, and so there's just some weird VT escape sequences you've never heard of in there.
You can also use SIXELs if you want even more control, and you can readily see such things in action because qemu can (in 2026) send its graphical VGA display into a sixel terminal, but in the 1980s such a thing would not have been performant (probably something like 3 frames per minute) because the VT330 was slow, and such a thing would not be popular you would "lose the text" at some layer which would be as inconvenient as using any other graphical application.
No amount of cartoons or colourful bouncy animation of pictures on the screen can replace simply displaying text when what you need to do is display text on the screen. And it turns out that text is a really good way to display information.
A picture is worth a thousand words but why would you use 1000 words when only one or two will do?
The latter is mostly because certain GUI patterns simply cannot be implemented with a TUI.
And then everyone has their own idea of what keyboard shortcuts should be like. Yuck
For those workflows (as opposed, to say, Photoshop), we could do without that. That's the whole benefit.
>and being self-explanatory and same-y.
GUIs are quite less same-y that TUI. Not to mention the same app GUI can be widely different between 2010 and 2026, whereas any TUIs from 1990s I still use look and work the same.
I personally prefer same font (one I choose) everywhere opposed to "whichever font developer likes for his app).
TUI apps are quick, efficient, portable and usable through ssh. If crisp graphics is the only downside I really don't mind.
Yeah, I think that is 90% of it. And the whole related ecosystem aspect. All the major ways of building GUIs suck right now, especially for tiny apps. And to further exacerbate the problem, GUI frameworks are generally tied to their programming languages, Qt is C++, SwiftUI is Swift, Flutter is Dart so on; spewing some terminal escapes to stdout is something that can done from basically any language with relative ease.
A macOS AppKit/Cocoa app uses like 30mb memory and is quite nice to develop or vibe-code. But the whole UX of it is the opposite of a TUI you can run in yet another pane of your terminal emulator next to the other panes you're working in.
GUI apps certainly have their place. But sometimes you want a UX like lazygit where you can launch it in cwd and be done rather than alt-tab to a GUI, open pwd inside it, then alt-tab back to the terminal.
Bypassing all that crap is the main benefit. I don't want any of that superfluous, and ever-changing stuff, when the terminal and, if needed, a TUI, is enough. As a bonus, it works everywhere I can ssh to.
>If all we work in are these super-lean TUIs maybe we don't even need so powerful computers or such high-DPI displays anymore?
For a lot of stuff, you never needed it. For others, like an IDE, DTP, gaming, 3D modelling, video editing, photo editing, they're amazing.
I think people are confused and think they like TUIs because they like them being keyboard driven etc. But this could all be done with a GUI.
The other factor is probably just fashion. Similar to how some kids are now listening to music on cassette tapes, which are objectively worse than other media in almost all respects. The less cynical take is it's like vinyl: it does come with compromises but gives us back some of the things we lost over the years.
The actual interesting text-based interface is the CLI. I've seen a few examples of TUIs that really should be a CLI and would be much more useful as such.
So, cool nerdy blog posts on HN, cool nerdy puzzles on Cracking the Cryptic, etc.
Having been sorta involved in hiring in the same sorta market, I can respect how astute their approach is.