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've been making a modern Slack terminal client (https://github.com/gammons/slk) and it's been a joy to use daily. There are a few things that IMO have unlocked a fantastic TUI experience:
- 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 really enjoy using Golang to make TUIs and the Charm ecosystem.
> But I think we will swing back to using GUIs
I've been pushing on BubbleTea Kitty and Ghostty quite a bit to hybridize this. The TUI / GUI distinction to me is about task centrism and delivery. There's an appropriate surface and workflow for every task; beyond TUI/GUI sometime it needs to be a VR headset or an immersive room or a literal sandbox.
A demo of this is web-delivery of our BubbleTea TUI examples ('t' toggles between glyph/kitty):
The delivery uses our WIP Booba tool, which is Ghostty-based. The CLI tool can be used to remote or embed any TTY program, but was generally built for BubbleTea.
https://github.com/NimbleMarkets/go-booba
Right now I'm working on multiple ds4 TUIs using this stack, for example generating SVGs from a prompt and then rendering it in TUI. Another generates CSG object graphs and renders/composites them in terminal. Here's a gist with screenshots:
The upstream ds4 project is using C for their TUIs. I have done TUIs in C and C++ (and many other languages) and will not go back to that. Really fun engine though and a great place to stick a TUI. I am a Camel furry (https://cameltopia.org) but wouldn't use OCaml to make a TUI either (makes sense for Jane Street of course).
> 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 might be missing something here, but wouldn't any UI toolkit that doesn't live within a WebView work?
Yes, and of those, my impression is that there are niche ones that look OK, game engines that look great but take a lot of work, and then there's just TUIs, which look retrocool and run blazing fast, and are really easy to write.
> and then there's just TUIs, which look retrocool and run blazing fast, and are really easy to write
I mean, I don't even think that's true. Many TUIs are bloated, dogshit slow, and it's not trivial to write complex TUIs without glitches or flickering. The more people start making TUIs because it's the current fad, the worse they will get.
You're probably right. TUIs (being old) have selection bias towards quality. However, my experience writing TUIs is that it's not even the same class of difficulty as writing GUIs. GUIs by any means have way more overhead and learning curve. Not to mention that a TUI is more likely to be immediately CLi compatible via adding a --no-tui flag, or CLI patchable via --tui.
> But I think we will swing back to using GUIs when we find a performant way of making them
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.
> I think mostly this renaissance is partly due to the current bloat of Electron GUIs.
I think it's mostly due to the CLI being much more powerful than a full-blown IDE: when you try to make everything simple (in a menu, accessible with one mouse-click or a shortcut), then semi-advanced things (which haven't been thought of in the IDE) become impossible.
They also compose way more easily with the network: it's much easier to SSH/tmux TUIs than to try to network GUIs. That's very important in this day and age of incessant exploits and the need to run things in VMs to try to prevent exploits from pwning your entire world.
TUIs sadly doesn't entirely solve the bloat issue: look at Claude Code CLI... An Electron app because, as the Pi author mentioned, people at Anthropic thought they were writing a game. A full headless Electron app converted, on the fly, to pretend it's a TUI.
The madness is real (shitload of message of users not happy with characters shown on screen not being those saved to source files: and I've been bit by this) and the bloat issue hasn't been solved.
But in any case you cannot go back to a GUI and not have that problem of GUIs being too restrictive: invariably there shall be a need to chain several simple commands that do one thing and that excel at that one thing and that only become powerful when chained with other commands. GUIs cannot solve that.
LLMs have just proved what many knew all along: that the CLI is more powerful.
Instead of GUIs on the contrary I expect more TUIs, more command line, and more, much more, REPL usage by LLMs and by devs using LLMs.
What I do hope though is that we get more lean TUIs (like Pi by Mario Zechner, all the utils written in Rust etc.) and less madness like "headless Electron converted 60 times per second to a fake TUI".
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.
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!
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).
My take is that GUI frameworks/APIs have abandoned power users.
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.
WaveTerminal which I use on and off is sort of a graphical terminal like that. Has gui widgets that tile inside the terminal doing alot of the things you might open another pane for IE:file manager resources etc.
Probably not as extensive as you mean but its sort of a stepping stone.
> 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.
> 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.
> 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?
Yes such-a-thing-is-possible: The DEC VT330 (for example) allowed font upload, had multiple font sizes, and even mouse support.
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.
Right, not having to leave the terminal is a big one for me too. I live there and every time I start some desktop app, I gotta switch gears, potentially grab the mouse, leave my vim keybinds behind and leave my font and color scheme behind. I just feel more productive on the terminal then on desktop apps.
I think also a big problem of desktop apps is that you have to deal with window management. Now that I am on Niri it is really apparent to me how much I hated juggling windows in pretty much any other window manager that I ever used, except, interestingly enough, tmux.
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.
It doesn't technically have to. But if you want to do it in a different location than the terminal window and have it be cross-platform and easy to develop for your options are limited. There are not really very many text-first UI frameworks out there that are cross platform. It's similar I think to the way that the browser has become the dominant GUI platform for development. The Terminal standards are fast becoming the dominant platform for Text First Interfaces.
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.
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.
IMHO peak GUI was in 2000s - on Windows most app used Win32 API and apps which followed "Microsoft Windows User Experience" guide had consistent UI/UX. Since then Microsoft introduced many competing frameworks to create GUI all look slightly different and UX is less consistent too. And then Electron come which brought inconsistency of web to the desktop apps.
That is very rose-tinted view of the era. In reality in early 00s lots of software had their own wacky UI toolkits. MS Office is of course the most notable example, but also iirc all of Adobe/Macromedia or every 3d modeling (Lightwave, Maya etc) and audio production software. In the enterprise realm people were doing Java AWT (and later Swing) UIs. And then there were the classics like WinAmp with its iconic theme support, or Mozilla with XUL (and themes).
>Unfortunately, they often lack what we gained over the last decades. Namely navigating with a mouse
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.
Yeah, but as far as I'm aware you get to pick one font and one size as long as the UI is laid out with literal ASCII spaces and newlines. You can't have tooltips with a smaller font, or code and prose together with monospaced/serif fonts accordingly.
To me they are much better than browser/electron/native gui because they are light on resources, very predictable, portable and honestly they get the job done. I used k8s Lens and it gave the impression of being efficient because of the high density of information, but I haven't felt like I downgraded when I moved to k9s, and now I can manage my clusters, develop their charts using neovim and browse the web without getting dangerously close to filling 16GB of ram. Before with Lens, Pycharm and a browser that would swallow the ram whole and spit its decaying bones to the swap unreasonably often.
On k8s/devops tooling: I'm building tuis.nvim [1] — Docker and Kubernetes management as Neovim buffer TUIs, built on morph.nvim [2], a react-like UI framework for Neovim. Stay in the editor (if you already use Neovim, of course) instead of switching to k9s, works over SSH, same Vim keybindings you already use. Also has plugins for Bitwarden, process management, and file exploration.
To me particularly, leaving editor isn't a hassle because kitty makes it seamless. Neovim, k9s, zsh shell, agents, it feels like it's just a single IDE, and I believe that specialized tools are simpler and more robust to maintain instead of adding functionality that wasn't intended for neovim. Don't get me wrong, neovim is sufficiently flexible for this, it's just that I had too much agro with neovim extensions that I just prefer native tools.
That is a valid point of view. For me, however, I have found a huge productivity boost being able to stay in Neovim for extended periods of time. That's not to say that my way is the only right way, but the more I'm able to accomplish in Neovim, the less friction I personally experience.
When you get down to it, there is no better way to display text than to use a text display.
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?
TUIs have this really nice attribute of running local to the data you care about (web apps have a lot of complicated glue code required to do interesting things), and in a UI that is incredibly simple to test and iterate on because the output can be serialized to a text file with very minimal loss of fidelity.
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.
> 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.
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.
Qt and GTK has bindings for a lot of languages. calibre is Qt built with python. And GTK has GI which allows to basically autogenerate bindings. It’s not plug and play, but it’s not difficult either.
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
>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.
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.
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.
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.
The whole UI seems better for LLMs to consume and also displays nicely in-editor for humans. Test failures become failing screenshot tests essentially, which are really comfortable changes to review.
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've been making a modern Slack terminal client (https://github.com/gammons/slk) and it's been a joy to use daily. There are a few things that IMO have unlocked a fantastic TUI experience:
- 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 really enjoy using Golang to make TUIs and the Charm ecosystem.
> But I think we will swing back to using GUIs
I've been pushing on BubbleTea Kitty and Ghostty quite a bit to hybridize this. The TUI / GUI distinction to me is about task centrism and delivery. There's an appropriate surface and workflow for every task; beyond TUI/GUI sometime it needs to be a VR headset or an immersive room or a literal sandbox.
A demo of this is web-delivery of our BubbleTea TUI examples ('t' toggles between glyph/kitty):
https://nimblemarkets.github.io/ntcharts/demos/heatpicture-p...
The delivery uses our WIP Booba tool, which is Ghostty-based. The CLI tool can be used to remote or embed any TTY program, but was generally built for BubbleTea. https://github.com/NimbleMarkets/go-booba
I've recently made SVG, PDF, SVG, and OpenStreetMap widgets.... https://github.com/NimbleMarkets/ntcharts-svg https://github.com/NimbleMarkets/ntcharts-pdf https://github.com/NimbleMarkets/ntcharts-osm
Right now I'm working on multiple ds4 TUIs using this stack, for example generating SVGs from a prompt and then rendering it in TUI. Another generates CSG object graphs and renders/composites them in terminal. Here's a gist with screenshots:
https://gist.github.com/neomantra/ae47422c8daf7a458212c93992...
The upstream ds4 project is using C for their TUIs. I have done TUIs in C and C++ (and many other languages) and will not go back to that. Really fun engine though and a great place to stick a TUI. I am a Camel furry (https://cameltopia.org) but wouldn't use OCaml to make a TUI either (makes sense for Jane Street of course).
Yep, that's about it. I am making a TUI for non-techies, packing it with Ghostty, and sending it to non-techies to use:
https://github.com/weedonandscott/trolley
Cool idea!
Soooo... lib ghostty supports the kitty (but not sixel) terminal image format.
> 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 might be missing something here, but wouldn't any UI toolkit that doesn't live within a WebView work?
Yes, and of those, my impression is that there are niche ones that look OK, game engines that look great but take a lot of work, and then there's just TUIs, which look retrocool and run blazing fast, and are really easy to write.
> and are really easy to write.
And, sometimes, all you want is to output text.
> and then there's just TUIs, which look retrocool and run blazing fast, and are really easy to write
I mean, I don't even think that's true. Many TUIs are bloated, dogshit slow, and it's not trivial to write complex TUIs without glitches or flickering. The more people start making TUIs because it's the current fad, the worse they will get.
You're probably right. TUIs (being old) have selection bias towards quality. However, my experience writing TUIs is that it's not even the same class of difficulty as writing GUIs. GUIs by any means have way more overhead and learning curve. Not to mention that a TUI is more likely to be immediately CLi compatible via adding a --no-tui flag, or CLI patchable via --tui.
> But I think we will swing back to using GUIs when we find a performant way of making them
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
I agree. The only reason I use TUI is because GUI are very slow with electron.
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.
> I think mostly this renaissance is partly due to the current bloat of Electron GUIs.
I think it's mostly due to the CLI being much more powerful than a full-blown IDE: when you try to make everything simple (in a menu, accessible with one mouse-click or a shortcut), then semi-advanced things (which haven't been thought of in the IDE) become impossible.
They also compose way more easily with the network: it's much easier to SSH/tmux TUIs than to try to network GUIs. That's very important in this day and age of incessant exploits and the need to run things in VMs to try to prevent exploits from pwning your entire world.
TUIs sadly doesn't entirely solve the bloat issue: look at Claude Code CLI... An Electron app because, as the Pi author mentioned, people at Anthropic thought they were writing a game. A full headless Electron app converted, on the fly, to pretend it's a TUI.
The madness is real (shitload of message of users not happy with characters shown on screen not being those saved to source files: and I've been bit by this) and the bloat issue hasn't been solved.
But in any case you cannot go back to a GUI and not have that problem of GUIs being too restrictive: invariably there shall be a need to chain several simple commands that do one thing and that excel at that one thing and that only become powerful when chained with other commands. GUIs cannot solve that.
LLMs have just proved what many knew all along: that the CLI is more powerful.
Instead of GUIs on the contrary I expect more TUIs, more command line, and more, much more, REPL usage by LLMs and by devs using LLMs.
What I do hope though is that we get more lean TUIs (like Pi by Mario Zechner, all the utils written in Rust etc.) and less madness like "headless Electron converted 60 times per second to a fake TUI".
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.
Hi ricky. No questions here, just a fan of yours.
Slightly OT, but the next logical steps include, in no particular order:
- 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
> frameworks for tui development
https://github.com/ratatui/awesome-ratatui
> - frameworks for tui development, including react-like DOM shit
React-ncurses FTW
I wish more terminals supported Tektronix and ReGIS graphics. We could do some really interesting visuals with those.
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!
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).
My take is that GUI frameworks/APIs have abandoned power users.
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.
WaveTerminal which I use on and off is sort of a graphical terminal like that. Has gui widgets that tile inside the terminal doing alot of the things you might open another pane for IE:file manager resources etc. Probably not as extensive as you mean but its sort of a stepping stone.
https://github.com/wavetermdev/waveterm
> 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?
> 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.
> 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?
Yes such-a-thing-is-possible: The DEC VT330 (for example) allowed font upload, had multiple font sizes, and even mouse support.
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.
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)
Right, not having to leave the terminal is a big one for me too. I live there and every time I start some desktop app, I gotta switch gears, potentially grab the mouse, leave my vim keybinds behind and leave my font and color scheme behind. I just feel more productive on the terminal then on desktop apps.
I think also a big problem of desktop apps is that you have to deal with window management. Now that I am on Niri it is really apparent to me how much I hated juggling windows in pretty much any other window manager that I ever used, except, interestingly enough, tmux.
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.
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
IMHO peak GUI was in 2000s - on Windows most app used Win32 API and apps which followed "Microsoft Windows User Experience" guide had consistent UI/UX. Since then Microsoft introduced many competing frameworks to create GUI all look slightly different and UX is less consistent too. And then Electron come which brought inconsistency of web to the desktop apps.
That is very rose-tinted view of the era. In reality in early 00s lots of software had their own wacky UI toolkits. MS Office is of course the most notable example, but also iirc all of Adobe/Macromedia or every 3d modeling (Lightwave, Maya etc) and audio production software. In the enterprise realm people were doing Java AWT (and later Swing) UIs. And then there were the classics like WinAmp with its iconic theme support, or Mozilla with XUL (and themes).
>Unfortunately, they often lack what we gained over the last decades. Namely navigating with a mouse
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.
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.
Yeah, but as far as I'm aware you get to pick one font and one size as long as the UI is laid out with literal ASCII spaces and newlines. You can't have tooltips with a smaller font, or code and prose together with monospaced/serif fonts accordingly.
To me they are much better than browser/electron/native gui because they are light on resources, very predictable, portable and honestly they get the job done. I used k8s Lens and it gave the impression of being efficient because of the high density of information, but I haven't felt like I downgraded when I moved to k9s, and now I can manage my clusters, develop their charts using neovim and browse the web without getting dangerously close to filling 16GB of ram. Before with Lens, Pycharm and a browser that would swallow the ram whole and spit its decaying bones to the swap unreasonably often.
On k8s/devops tooling: I'm building tuis.nvim [1] — Docker and Kubernetes management as Neovim buffer TUIs, built on morph.nvim [2], a react-like UI framework for Neovim. Stay in the editor (if you already use Neovim, of course) instead of switching to k9s, works over SSH, same Vim keybindings you already use. Also has plugins for Bitwarden, process management, and file exploration.
[1] https://github.com/jrop/tuis.nvim [2] https://github.com/jrop/morph.nvim
To me particularly, leaving editor isn't a hassle because kitty makes it seamless. Neovim, k9s, zsh shell, agents, it feels like it's just a single IDE, and I believe that specialized tools are simpler and more robust to maintain instead of adding functionality that wasn't intended for neovim. Don't get me wrong, neovim is sufficiently flexible for this, it's just that I had too much agro with neovim extensions that I just prefer native tools.
That is a valid point of view. For me, however, I have found a huge productivity boost being able to stay in Neovim for extended periods of time. That's not to say that my way is the only right way, but the more I'm able to accomplish in Neovim, the less friction I personally experience.
Neither is mine! I'd love to give it a try sometime, but still need to crunch through https://lazyvim-ambitious-devs.phillips.codes/ because my vimfu is sorely lacking
When you get down to it, there is no better way to display text than to use a text display.
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?
Real text lovers have an appreciation of typography and don't ignore the whole field and stay in the dirt with crude "monospace everything" approach.
If anything text lovers prefer GUIs for their proper rendering. Imagine if books looked like TUIs.
You can also sandbox TUIs, with full control of the sandbox parameters. To do this on macOS, you can use: https://multitui.com
TUIs have this really nice attribute of running local to the data you care about (web apps have a lot of complicated glue code required to do interesting things), and in a UI that is incredibly simple to test and iterate on because the output can be serialized to a text file with very minimal loss of fidelity.
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.
> 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.
I don't think much hinges on Electron here.
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.
Qt and GTK has bindings for a lot of languages. calibre is Qt built with python. And GTK has GI which allows to basically autogenerate bindings. It’s not plug and play, but it’s not difficult either.
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
>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.
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.
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.
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
The whole UI seems better for LLMs to consume and also displays nicely in-editor for humans. Test failures become failing screenshot tests essentially, which are really comfortable changes to review.
Questiom for TUI writers - in 2026 is there any terminal emulator that doesn't understand ecma 48 control codes?