I have had a similar notion, around the same time, with tui's and strace in particular. Lots of experiments, never quite good enough to publish or try to popularize. Something I've found in the last few years though, and especially the last six months, is that the impulse to make a better tui has died for me. Claude et al are going to wield these tools via cli far better than I can via tui. The built in visualization is nice for sure in tui, an embodied perspective on how to investigate something, however Claude can make a custom one for me in the moment within a few minutes. My impulse is to throw Claude at the issue with the bare linux toolbox while I do other things, not hand craft better tools that I don't have much motivation to use right now.
The deeper reason agents write good Bonsai_term code is that the entire UI renders as plain text, so a screenshot test is just a diff the model can read and verify on its own. A GUI's visual state needs a vision model to inspect, but a TUI's output already lives in the agent's native modality, which closes the feedback loop for free.
This isn't really much of an excuse given contemporary models though. My current game project has a GUI editor mode and it was not difficult at all whatsoever to set it up such that whenever I run a debug build of the game:
- It opens to the editor mode rather than the gameplay mode on launch
- It makes a .run/ directory next to the executable if one doesn't already exist
- It makes a timestamped directory within .run/ for this current debug run
- It automatically records stdout to stdout.txt, stderr to stderr.txt, and a crash.txt if the game crashes, in the directory for this run
- When the “take debug screenshot” function is invoked (which can be done by pressing F12), it saves a timestamped (based on time since executable launched) screenshot in the directory for this run
- Editor actions and 3D camera movements are recorded to playback.txt in the directory for this run
With all of this in place, I can do a debug build, run the game, do something in the editor, and take one or more screenshots where things went wrong. Then, Codex can see the log files and screenshots and try to diagnose the problem. When attempting to fix the problem, it can automatically recompile the debug build and rerun it with a launch option that plays back the latest recording file, which does the same sequence of editor actions/camera movements and takes screenshots at the same points in the process. Then it can compare this to the initial recorded run and see what needs to be fixed.
We could be having a GUI renaissance right now but for various primarily aesthetic reasons people are churning out TUIs, and personally I think it's a huge mistake.
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.
I think one of the big appeals of TUI's is that it is easier for it to be cross platform. Crush looks the same on macos and linux, provided you have your terminal setup correctly.
I don't really get the TUI craze. Would love it if someone has some perspective that I'm lacking.
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!
It's because of AI agents. People can talk about the other benefits all they want, but this is the real reason. Agents can use TUIs natively with basic written instructions, which is why they are exploding in popularity.
For me a TUI constrains the style of presentation to something reasonably good. In an era of websites with tiny light gray font on dark gray background, where scrolling is really a javascript page load, and the back arrow is not respected, I just want to simplify to something that works and is always the same and that I can read with my old eyes.
Somewhere along the way, GUIs seemingly went from economy of use to a graphical resume for the developer (or their manager).
> 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
To be fair to Jetbrains, users would get charged API prices if they built their own integration. Zed recently added support for terminal sessions in the agent chat history for precisely this reason. Blame Anthropic.
I've long been a tmux+vim user and one advantage is you can connect to exactly the same session from different places in a way just not practical with guis
I work on bonsai_term (though Jose is the primary author and many others have contributed incredible work). I'm happy to try and answer any questions that the post may bring up.
TUIs are just GUIs that use a grid of characters instead of pixels. They are strictly worse than true GUIs, by definition. The only thing I liked TUIs for is running over SSH, but can any of these newer ones really run over SSH with any kind of decent performance anyway?
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.
Always pains me to see all this innovation and cool software work being applies towards making a machine that extracts money from retail investors and makes a few people extremely wealthy. What a depressing and colossal waste of time.
Worth adding to the list: TUIs have found an unexpected new job as the "read" layer for AI agents — they already render exactly the state the agent needs (fleet health, live metrics, log tails) without a separate REST API, and the MCP server just maps that state to tool calls. The shared human/agent view is what makes it interesting. That's the direction we took with Servonaut, a server management TUI with a built-in MCP server: https://github.com/zb-ss/servonaut.
27 comments
[ 3.0 ms ] story [ 49.4 ms ] thread- It opens to the editor mode rather than the gameplay mode on launch
- It makes a .run/ directory next to the executable if one doesn't already exist
- It makes a timestamped directory within .run/ for this current debug run
- It automatically records stdout to stdout.txt, stderr to stderr.txt, and a crash.txt if the game crashes, in the directory for this run
- When the “take debug screenshot” function is invoked (which can be done by pressing F12), it saves a timestamped (based on time since executable launched) screenshot in the directory for this run
- Editor actions and 3D camera movements are recorded to playback.txt in the directory for this run
With all of this in place, I can do a debug build, run the game, do something in the editor, and take one or more screenshots where things went wrong. Then, Codex can see the log files and screenshots and try to diagnose the problem. When attempting to fix the problem, it can automatically recompile the debug build and rerun it with a launch option that plays back the latest recording file, which does the same sequence of editor actions/camera movements and takes screenshots at the same points in the process. Then it can compare this to the initial recorded run and see what needs to be fixed.
We could be having a GUI renaissance right now but for various primarily aesthetic reasons people are churning out TUIs, and personally I think it's a huge mistake.
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!
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!
Somewhere along the way, GUIs seemingly went from economy of use to a graphical resume for the developer (or their manager).
To be fair to Jetbrains, users would get charged API prices if they built their own integration. Zed recently added support for terminal sessions in the agent chat history for precisely this reason. Blame Anthropic.
- 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
https://github.com/ratatui/awesome-ratatui
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.