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 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.
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!
> 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,
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.
TUI returns what GUI lost over the last decades - low latency, low RAM/CPU usage, ability to navigate without a mouse. No one seems to be building nice GUI apps anymore.
> Is it because the perceived alternative is another run-off-the-mill Electron RAM guzzler, because there aren't any _good_ GUI widget frameworks?
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.
For me personally, it's because it retains the same window position, and I get back what I had before when it closes. If GUIs worked more like they did with windows in plan9, I'd definitely use them more
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.
Interesting that Jane Street has taken an interest in TUIs, I think mostly this renaissance is partly due to the current bloat of Electron GUIs.
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!
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.
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!
I appreciate TUIs for
- 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)
> 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,
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.
You've answered yourself if fourth paragraph. For me (and guessing for many other engineers) usability is more important than crisp visuals..
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.
TUI returns what GUI lost over the last decades - low latency, low RAM/CPU usage, ability to navigate without a mouse. No one seems to be building nice GUI apps anymore.
Unfortunately, they often lack what we gained over the last decades. Namely navigating with a mouse and being self-explanatory and same-y.
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
> Is it because the perceived alternative is another run-off-the-mill Electron RAM guzzler, because there aren't any _good_ GUI widget frameworks?
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.
For me personally, it's because it retains the same window position, and I get back what I had before when it closes. If GUIs worked more like they did with windows in plan9, I'd definitely use them more
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.
for snapshot tests it seems better to diff a data representation such as some yaml string, than to diff UIs