> Notably this was the first time I felt that using Claude Code for something non-arbitrary was significantly faster than doing it myself
Well, it is like code completion on a higher level.
I still don't like this approach. Besides, who is going to maintain that code?
Such code will probably forever be required to be maitnained via Claude. So no
humans involved. Just autogenerated stuff. I dislike this idea a lot.
Humans are slower, ok, but they built excellent software before Claude. What is
coming next? Claude Linux-like Kernel? Top500 supercomputers will run it?
Building a TUI was easy before, especially with the great toolsets for their respective languages BubbleTea / Textualize / Ratatui. And thanks to those frameworks, LLMs can manifest useful tools.
Similar to WebApps, it's only since the November'25 renaissance that I felt I could use them to create TUIs. Once I had that revelation, I started going into my backlog and using it.
I maintain a TUI Charting library, NTCharts. In January, I fixed a bug - totally obvious once identified - that I personally failed to find earlier. But the test harness, prompting, and Gemini got it done [1]. Gemini's spatial understanding was critical in completing the task.
I've been vibe-crafting a local LLM conversation viewing tool called thinkt. After scraping ~/.claude and making a data model, this is the point in PROMPTS.md where I start creating the TUI using BubbleTea. [2].
It's somewhat ironic that a web page about performant terminal user interfaces uses gratuitously complex CSS mask compositing and cubic gradients which reduce smooth scrolling on my 1 year-old, high-end Dell XPS laptop (>$3k) to Commodore 64 level (on default 'Balanced' battery mode). While it's pretty, it's also just a very subtle, non-critical background animation effect. Not being a CSS guru myself, here's what Gemini says:
> "Specifically, this is a Scrim or Easing Gradient. Instead of a simple transition between two colors, it uses 16 color stops to mimic a "cubic-bezier" mathematical curve. This creates a smoother, more natural fade than a standard linear gradient, but it forces the browser to calculate high-precision color math across the entire surface during every scroll repaint."
My Firefox smooth scrolls like butter on thousands of pages, so you might want ask your web designer to test on non-Mac, iGPU laptops with hiDPI and consider the performance cost of web pages with always-running subtle background animations in a world of diverse hardware platforms. In case it helps, here's the animation with the gradient layers disabled so you can see all 6,400,000 pixels which are being recalculated every scroll line (https://i.imgur.com/He3RkEu.jpeg).
You're right - I'll remove that now until we can get it more performant or drop it altogether. This wasn't something we caught during testing. I appreciate the feedback!
Building TUIs was already super easy in 1990 with Turbo Vision and Clipper on MS-DOS, with compiled languages (TP, xBase), using super fast build times on systems running at 10 Mhz, within 640 KB.
I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s a sorry state of affairs.
I disagree, I think TUIs are a great fit in some problem domains.
Think for instance the Debian package configuration dialogs -- they're far more comfortable than the same questions without a TUI, and still work over a serial console if you have to use one.
For tools like various kinds of "top", there's many potential tools you can use to the same end and intentionally using one that draws CPU graphs over one that just displays a number. Graphs are much easier to interpret than a column of numbers.
In many cases they're the optimal choice given some constraint -- like the desire to have minimal dependencies, working over SSH, and being usable without breaking the flow. Yeah, you could make a tunnel to a tool that runs a local webserver and delivers graphs by HTTP, but the ergonomics of that are terrible.
Sure, I said I understand why people build them. I’ve used a lot of them. And yes with the tools we have you’re right, but I’m more lamenting the wonky, kind of archaic, unintegrated, only-semi-composable toolset that we have. No fundamental reason why you couldn’t deliver more structured UIs directly over SSH or a serial console, it’s just that in this timeline that didn’t happen yet (apart from X forwarding, which isn’t quite what I’m on about).
The difference there, in Debian's case at least, is that there is a distinction between the frontend and the configuration backend; you're probably most familiar with the `newt` frontend, but there's also `text` (for textual entry without using curses or anything), `noninteractive` (for just use the defaults), gnome, kde, teletype, or even 'web' which does not seem to work effectively but is a neat idea regardless.
TUIs which are just TUI views of data you can get otherwise are fine; TUIs which are the only way to interact with something... less so.
>I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad.
You'd think that, but you'd be wrong. Case in point from Emacs/Vim and the Borland IDEs to Claude, plus all kinds of handy utils from mc and htop to mutt.
>They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely
That's not necessarily bad. Not everything has to be open ended.
Funnily, Emacs is getting closer to what I’m after (it’s my main editor).
> That's not necessarily bad. Not everything has to be open ended.
I think it is necessarily bad and everything should be open ended. Bad in the sense of low quality, but if we’re talking about critical accessibility (someone is unable to use your application at all), morally bad too.
How many developers are using VSCode? How does that number compare with Emacs/Vim?
In many ways, GUI was developed as the natural evolution of TUI. X server, with its client-server architecture, is meant to allow you to interact with remote sessions via "casted" GUI rather than a terminal.
Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.
Here's why I use them: many modern graphical applications are extremely wasteful. TUIs are typically small, low footprint applications that don't come bundled with a browser or webview. I don't need yet another electron app for every little thing.
I’m definitely not advocating more little electron apps, and I’m totally with you on TUI’s benefits. I’m bemoaning the lack of imagination that has ended us up here and not in a situation where we can have, say, a small, low-footprint application that can deliver a more structured UI with minimal dependencies. It’s not an impossibility, it’s not even that difficult to imagine, we just don’t have the exact technology.
Yes, but this kind of dashboard was never going to be accessible anyway. It's a dense visual representation of vast system state with constant real-time fluctuation. Even in a browser, it would be hell to navigate the constantly changing state with a screen reader. And visually increasing the scale and contrast defeats the purpose of the density of the original display.
If you need to support screen readers, your UI would have to be totally different: You should allow the user to snapshot the system state and navigate it. Generate succinct summary text to impart the same sense that a dashboard would to a visual user. "Normal: All systems OK" "Critical: Boeing RPA servers down since 2:17PM PDT and 54 others". Once you've done this work, a CLI tool could expose this just as screen-readable:
$ cli status
all systems OK, last outage resolved 2:27 PDT
$ cli topjob cpu
117 Boeing RPA, 78% CPU
434 SAIC PDM, 43% CPU
$ cli downtime today 117
Boeing RPA down 10 minutes today, resolved now
I’m not just talking about screen readers, though they are important. I mean “accessible” more generally. Yes you could build a specific UI for each kind of user, but that seems far less likely to cover as many uses as building one UI that is structured, programmatically navigable, etc.
Not even close. Apple UIs - despite recent graphical howlers - have excellent accessibility APIs and are regularly praised by people that track such things. I’ve recently been building a macOS app and the UI testing is also based off it. There are apps that allow full keyboard navigation using it. I do agree that the window management side is much less customisable, though, and that does frustrate me.
I think I see your point. I've had it in the back of my head too.
Guess it's like the separation between backend and front-end. When the logic is neatly wrapped in a nice API you can potentially get a lot of reusability from that since the API can be integrated into other things with other use cases.
But a TUI probably doesn't naturally come with a separate backend. However, if a cli is built in a non TUI way it is about as flexible as a backend. Output can be streamed into pipes etc.
I can't stream k9s output into a pipe or variable but I can with kubectl.
Would be nice if we could have the cake and eat it here. Can TUI frameworks encourage having it both ways?
They are GUIs --- just minecraft GUIs. One day, we will rediscover why GUI toolkits exist. The only real advantage TUIs have over GUIs is easy remoting, TBH. Maybe that's enough for people. Otherwise? They're just hair shirts.
I've use Claude to make myself a number of little tools and weird apps that only I would want lately. They need to be cross-platform between Linux and Mac and sometimes Windows. The best approaches I've found are Tauri (+Svelte for making layout easier) for lightweight GUIs but for anything more complex I prefer a TUI. The Ratatui framework works very well. A TUI feels like a "real" app as opposed to a glorified webpage. For actually serious software I'd want a native GUI on each platform.
Maybe we just need to go all the way: How about a WASM core with a React GUI that runs inside a custom Electron renderer which outputs the TUI? 100% CPU guaranteed. And you'll never find that important piece of information in an all-monochrome wall of text with no icons. Why use a low-level print() when you could improve your productivity with a high-level framework? /s
As LLMs consume all our compute resources and drive up prices for the compute hardware on which we run applications, the silver lining is that LLMs are helpful in implementing tooling without a heavy stack so it will run quickly on a lower-spec computer.
I've achieved 3 and 4 orders of magnitude CPU performance boosts and 50% RAM reductions using C in places I wouldn't normally and by selecting/designing efficient data structures. TUIs are a good example of this trend. For internal engineering, to be able to present the information we need while bypassing the millions of SLoC in the webstack is more efficient in almost every regard.
I suspect that a native GUI, or even something like GPUI or Flutter would be still more performant than TUI's, which are bound by the limitations of emulating terminals.
A very important thing about constraints is that they also liberate. TUIs automatically work over ssh, can be suspended with ctrl-z and such, and the keyboard focus has resulted in helpful conventions like ctrl-R that tend to not be as prominent in GUIs.
The question is how many decades each user of your software would have to use it in order to offset, through the optimisation it provides, the energy consumption you burned through with LLMs.
When global supply chains are disrupted again, energy and/or compute costs will skyrocket, meaning your org may be forced to defer hardware upgrades and LLMs may no longer be cost effective (as over-leveraged AI companies attempt to recover their investment with less hardware than they'd planned.) Once this happens, it may be too late to draw on LLMs to quickly refactor your code.
If your business requirements are stable and you have a good test suite, you're living in a golden age for leveraging your current access to LLMs to reduce your future operational costs.
Would it be that many? Asked AI to do some rough calculation, and it spit that:
Making 50 SOTA AI requests per day ≈ running a 10W LED bulb for about 2.5 hours per day
Given I usually have 2-3 lights on all day in the house, that's like 1500 LLM requests per day (which sounds quite more than I do).
So even a month worth of requests for building some software doesn't sound that much. Having a local beefy traditional build server compling or running tests for 4 hours a day would be like ~7,600 requests/day
In the past week I made 4 different tasks that were going to make my m4brun at full tilt for a week optimized down to 20 minutes with just a few prompts. So more like an hour to pay off not decades. average claude invocation is .3 wh. m4 usez 40-60 watts, so 24x7x40 >> .3 * 10
Especially considering that suddenly everyone and their mother create their own software with LLMs instead of using almost-perfect-but-slighty-non-ideal software others written before.
I’m not really worried about energy consumption. We have more energy falling out of the sky than we could ever need. I’m much more interested in saving human time so we can focus on bigger problems, like using that free energy instead of killing ourselves extracting and burning limited resources.
I think mc (Midnight Commander) is still one of the best TUIs available - it's very close in capability to the GUI versions (like Double Commander) and it has the benefits of tuis - like that you can run it on a remote system.
It looks outdated, but I'm actually now working on a new skin that will hopefully be included in the next release of mc.
It’s a very cumbersome UI that feels extremely bloated. Especially if you have a lot of text you want to scroll over — eg i want to see the details of the last X exchanges - it just performs absolutely horribly.
It seems like it already was like this from the start, though? I’m not a frontend / TUI dev, but why are these issues so hard to fix?
I don't see any real advantage of TUIs over web forms or GUIs for the same thing.
I do like CLIs though, especially the ones that are properly capable of working in pipelines. Composing a pipeline of simple command-line utilities to achieve exactly what you want is very powerful.
There are some applications/systems for which certifying bodies forbid the use of web management because of vulnerabilities in both the protocols and the clients and servers. For example, in my daily, several national cyber organizations (NSA, CSE, GCHQ, etc.) have such direction. That's why our main product line is managed using a TUI accessed at the local console or over SSH (with very, very carefully curated SELinux MAC, among other things).
Having said that....
If one is willing to build one's own HTTP server with integrated MAC, etc., and is able to demonstrate mitigations against known vulnerabilities, one may be able to get the certifying bodies on board. Time will tell.
Yes, this is very niche, but TUIs are in general niche.
I like a TUI when I always want an app to run side by side with a CLI. It’s easier to do split windows in a terminal or tmux/zellij panes than to script two separate app windows to stay locked together as a pair. Although, I’d welcome advice as to how to do it better.
I also find TUIs are easier to program for the same reason they’re limited. Fewer human interface aspects in play and it’s not offensive to use the same UI across OSes. (There are still under-the-hood differences across OSes, e.g. efficient file event watching.)
Gemini made a lovely TUI for my C# project, but afterwards it said it could just spin up a Kestrel web server inside the app instead which would be a much better solution for managing it, which was fair. (I have a line in my Agents to warn me when I specify a way of building something and it's not the ideal solution)
> I have a line in my Agents to warn me when I specify a way of building something and it's not the ideal solution
And that helps? I tried that a while ago and it very often said this is not a good way of doing something even though it was objectively the best way of doing something. I removed it after a while because it was too random.
In practice, TUIs tend to have good keybindings, & are readily available right in the place where you're running the command (especially for quick tasks).
They can, but don't always. I've used some where you have to smash the TAB key 50 times go move linearly through all the fields and controls. If there are well-implemented navigation keys, yes they it can be very efficient.
Having a tui file picker in the pipeline can be a powerful technique. Sometimes it just makes sense to have an interface that is slightly more interactive than pre-selecting all the files makes the flow smoother. Being able to put that into a script/alias/whatever is nice.
Other CLI things benefit from this "have a minimal ui interface in the workflow for the one step where it makes sense".
I just added a TUI built on Charm for my custom agent. I primarily use it for two things.
1. Navigating all my chat sessions and doing admin work. It's super fast to push a single key to go in and see what it was about before deleting it.
2. Testing out features and code changes without the web UI / vs code extension complexity.
3. Places where I cannot connect VS Code. I still want to chat and see diffs, a TUI is much easier than a CLI for this.
It also has a CLI, basically three interfaces (CLI, TUI, GUI (vscode/webapp)) to the core features of my personal swiss army knife (https://github.com/hofstadter-io/hof)
It was like two-shot, cos the first version had some issues with CJK chars.
I was impressed as it would have taken me a bunch of screwing around on lining up all the data etc when I wanted to concentrate on the scraping algorithm, not the pretty bits.
I’d be interested to hear more about your project. I’ve heard about other DHT related things like search engines and such using it, but I haven’t explored the space much myself.
With Claude, I built a TUI for managing QEMU/KVM VMs (Rust with ratatui.) Solves a lot of problems I had with virt-manager, so I made it a FOSSS project. https://www.vm-curator.org.
Hi everyone, I enjoyed building this TUI for myself and wanted to write down how I did it. I appreciate all the thoughts and feedback! The web app is our main investment, but I think there's a slice of developers who really like to interact with TUIs, so I'm going to keep working on it.
For the demo at https://tui.hatchet.run, to answer some messages asking about it: I built this with the fantastic ghostty-web project (https://github.com/coder/ghostty-web). It's been a while since I've used WASM for anything and this made it really easy. I deployed the demo across six Fly.io regions (hooray stateless apps) to try to minimize the impact of keystroke latency, but I imagine it's still felt by quite a few people.
I haven’t done much with Claude code yet but I’ve watched some rather recent videos of other people leverage it to get work done and I couldn’t help thinking, are we going to end up with a similar UI but with fully deterministic “agents” at the end of this hype cycle.
All of the skills I saw demonstrated were deterministic. So does this end in a Functional Core, Imperative Shell scenario that looks like a Terraform Plan and a search engine-style natural language processor out front?
I too enjoy the charm TUI libraries, and have been using them to build a settlers of Catan game[0]. And some features are really cool, like different colors depending on dark/light theme.
They have a bunch of functions that concatenate strings, which may not be very efficient compared to using string.builders, but I haven't yet had performance problems.
However I haven't had such a great experience with AI, IMO they're bad at ASCII art.
Indeed. Over a few days of iterations I had this TUI built for fast full-text search of Claude Code or Codex sessions using Ratatui (and Tantivy for the full-text search index). I would never have dreamed of this pre coding agents.
If it was so easy Anthropic wouldn't have messed up CC for so long. The author takes for granted the availability of good off-the-shelf TUI libraries for his chosen language.
TUIs are great fun and Claude can make beautiful ones with a little ratatui action super fast. However, the downside of these are that you can't use them with Claude Code so while I have a few I prefer to also have a prompt-response CLI function since that's better for lots of things.
Not sure if this satisfies your requirements, but I've gotten Claude Code to run commands in tmux and view their output (including debugging my NeoVim config), so I think that a TUI is at least accessible, even though it would likely bloat the context window far more than a simple CLI.
Yeah, this is my main way of using Claude Code for anything complex – a REPL or bash window in tmux, and with Claude running commands there. That lets me easily browse through anything that's happened in a UI I'm used to, or manually intervene if needed.
The article talks about this and in fact talks about how one of the advantages of the TUI was that by combining it with `tmux capture-pane` it ended up easier for Claude to use and iterate on, not harder.
Claude Code has done a good job of building a tui MUD client (I couldn’t find one I liked), and then building a GUI version using Tauri where all the config is shared, so you can run it as either a GUI (on any platform) or TUI. Happy with it so far, and I personally use both TUI mode or GUI mode (with floating panes) depending on what I’m doing.
I want my interfacing with computers to be mouseless and TUIs offer that. I don’t think I’ve run into a GUI, no matter how many hotkeys it has and I know, where I didn’t have to reach for the mouse.
CLI only also requires remembering commands, some of which I use very infrequently, thus need to look up every time I use them.
I think TUIs hold a very nice spot between GUIs and CLI.
VS Code with the Vim extension is largely mouseless
I use the TUI from a terminal tab in VS Code, my agent works with that and the custom extension with a webapp based interface, seamlessly and concurrently
GUIs, TUIs, and PR/kanban all make sense in different situations. We'll all use at least two of them on regular basis for coding agents.
Big reason why TUIs were popular in the first place is because they are so much simpler to build. Compare ncurses to GTK/Qt, they are completely different leagues. One of my pet ideas is to build a ncurses compatible/style library that skips terminal layer and instead renders directly to Wayland, kinda getting the simplicity of ncurses without dragging all the legacy junk with it.
Yet ironically getting Claude Code to run at 60fps is way way harder in a TUI? Kinda funny that they optimized for "simple" then footgunned themselves into a client that probably took thousands of man hours to get to a reasonable place for power users.
If you have a TUI the correct way to support mobile browsers is to 1-shot a React page equivalent. Trying to make the mobile keyboard work for this would be silly.
I was working on a fairly niche thing, a library of crossplane compositions written in KCL and thought it would be nice to have a TUI so i could browse through them and see the rendered yaml as claude was working on it. I asked claude code to write it with python and textual and it one shotted it in about two minutes including a test suite.
Dagger has a really nice TUI built on Charm. It reads OTEL to create an interactive tree for your builds and containers. If you have cloud setup, it will also push that all to a webapp interface where you can share and navigate in perpetuity. This works for both CI and local runs, super cool for sharing links to failed builds during dev, even while the dev's local build is still running
The problem with TUI's, that we have all Stockholm syndrom'd ourselves, is that I can't use the mouse cursor to click to the position on the screen and edit the command line.
Emacs vterm can do this. It's the only terminal emulator I'm aware of that can, because it seems nobody else cares. It can even backspace and delete all the text selected.
FWIW, Plan 9 windows work this way. They are just plain UTF-8 buffers with no typewriter emulation. You can edit any text you wish. If you want graphics, the draw device is a 2D graphics compositor you load assets into then issue rendering commands. Text is a draw primitive and easily displayed any way you want, angled, rotated, moving around, colorful. VT emulation is accomplished by vt(1) which does VT over stdio and emulates an ANSI typewriter using the draw device and it works well. You could even write a Plan 9 native TUI That way, just run it under vt(1). But I would not recommend that - go native.
possible isn't the same as supported and working. A non-terminal hunt-and-peck typer sits down and is presented with a terminal, what's the second that happens when they're typing? they make a mistake and try to click on the word they misspelled, and it doesn't work.
It runs poorly, loses keystrokes, and easily gets bogged down with too much terminal input.
I don't want candy coated monospace ASCII graphics. I want something fast and functional. The graphics are _entirely_ secondary. You've missed the point of what a TUI is.
Terminals still have poor keyboard support these days, starting with the Escape key (which should not be ASCII 27 IMO) and various ctrl/shift/alt... key combinations.
> Notably this was the first time I felt that using Claude Code for something non-arbitrary was significantly faster than doing it myself
Well, it is like code completion on a higher level.
I still don't like this approach. Besides, who is going to maintain that code? Such code will probably forever be required to be maitnained via Claude. So no humans involved. Just autogenerated stuff. I dislike this idea a lot.
Humans are slower, ok, but they built excellent software before Claude. What is coming next? Claude Linux-like Kernel? Top500 supercomputers will run it?
Building a TUI was easy before, especially with the great toolsets for their respective languages BubbleTea / Textualize / Ratatui. And thanks to those frameworks, LLMs can manifest useful tools.
Similar to WebApps, it's only since the November'25 renaissance that I felt I could use them to create TUIs. Once I had that revelation, I started going into my backlog and using it.
I maintain a TUI Charting library, NTCharts. In January, I fixed a bug - totally obvious once identified - that I personally failed to find earlier. But the test harness, prompting, and Gemini got it done [1]. Gemini's spatial understanding was critical in completing the task.
I've been vibe-crafting a local LLM conversation viewing tool called thinkt. After scraping ~/.claude and making a data model, this is the point in PROMPTS.md where I start creating the TUI using BubbleTea. [2].
[1] https://github.com/NimbleMarkets/ntcharts/issues/7#issuecomm...
[2] https://github.com/wethinkt/go-thinkt/blob/main/PROMPTS.md#2...
Alex,
It's somewhat ironic that a web page about performant terminal user interfaces uses gratuitously complex CSS mask compositing and cubic gradients which reduce smooth scrolling on my 1 year-old, high-end Dell XPS laptop (>$3k) to Commodore 64 level (on default 'Balanced' battery mode). While it's pretty, it's also just a very subtle, non-critical background animation effect. Not being a CSS guru myself, here's what Gemini says:
> "Specifically, this is a Scrim or Easing Gradient. Instead of a simple transition between two colors, it uses 16 color stops to mimic a "cubic-bezier" mathematical curve. This creates a smoother, more natural fade than a standard linear gradient, but it forces the browser to calculate high-precision color math across the entire surface during every scroll repaint."
My Firefox smooth scrolls like butter on thousands of pages, so you might want ask your web designer to test on non-Mac, iGPU laptops with hiDPI and consider the performance cost of web pages with always-running subtle background animations in a world of diverse hardware platforms. In case it helps, here's the animation with the gradient layers disabled so you can see all 6,400,000 pixels which are being recalculated every scroll line (https://i.imgur.com/He3RkEu.jpeg).
You're right - I'll remove that now until we can get it more performant or drop it altogether. This wasn't something we caught during testing. I appreciate the feedback!
While you are at it, it would be good, if the post was readable at all, without having to run JS on the page.
1 reply →
"you're absolutely right!"
1 reply →
> to Commodore 64 level
That’s unfair to C64 which can smooth scroll very well.
I owned a C64. Remember how buttery smooth the interfaces of those '80s computers were?
2 replies →
Not by repainting the whole screen every frame!
1 reply →
Notice how many times Claude Code was mentioned in this blog post nee advertisement?
FWIW, this page looks just fine in a text-only browser running in textmode, no X11, no Javascript, no CSS, on an old, underpowered computer
Building TUIs was already super easy in 1990 with Turbo Vision and Clipper on MS-DOS, with compiled languages (TP, xBase), using super fast build times on systems running at 10 Mhz, within 640 KB.
I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s a sorry state of affairs.
I disagree, I think TUIs are a great fit in some problem domains.
Think for instance the Debian package configuration dialogs -- they're far more comfortable than the same questions without a TUI, and still work over a serial console if you have to use one.
For tools like various kinds of "top", there's many potential tools you can use to the same end and intentionally using one that draws CPU graphs over one that just displays a number. Graphs are much easier to interpret than a column of numbers.
In many cases they're the optimal choice given some constraint -- like the desire to have minimal dependencies, working over SSH, and being usable without breaking the flow. Yeah, you could make a tunnel to a tool that runs a local webserver and delivers graphs by HTTP, but the ergonomics of that are terrible.
Sure, I said I understand why people build them. I’ve used a lot of them. And yes with the tools we have you’re right, but I’m more lamenting the wonky, kind of archaic, unintegrated, only-semi-composable toolset that we have. No fundamental reason why you couldn’t deliver more structured UIs directly over SSH or a serial console, it’s just that in this timeline that didn’t happen yet (apart from X forwarding, which isn’t quite what I’m on about).
1 reply →
The difference there, in Debian's case at least, is that there is a distinction between the frontend and the configuration backend; you're probably most familiar with the `newt` frontend, but there's also `text` (for textual entry without using curses or anything), `noninteractive` (for just use the defaults), gnome, kde, teletype, or even 'web' which does not seem to work effectively but is a neat idea regardless.
TUIs which are just TUI views of data you can get otherwise are fine; TUIs which are the only way to interact with something... less so.
1 reply →
>I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad.
You'd think that, but you'd be wrong. Case in point from Emacs/Vim and the Borland IDEs to Claude, plus all kinds of handy utils from mc and htop to mutt.
>They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely
That's not necessarily bad. Not everything has to be open ended.
Funnily, Emacs is getting closer to what I’m after (it’s my main editor).
> That's not necessarily bad. Not everything has to be open ended.
I think it is necessarily bad and everything should be open ended. Bad in the sense of low quality, but if we’re talking about critical accessibility (someone is unable to use your application at all), morally bad too.
How many developers are using VSCode? How does that number compare with Emacs/Vim?
In many ways, GUI was developed as the natural evolution of TUI. X server, with its client-server architecture, is meant to allow you to interact with remote sessions via "casted" GUI rather than a terminal.
Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.
TUI just got the nostalgia "coolness".
6 replies →
Here's why I use them: many modern graphical applications are extremely wasteful. TUIs are typically small, low footprint applications that don't come bundled with a browser or webview. I don't need yet another electron app for every little thing.
I’m definitely not advocating more little electron apps, and I’m totally with you on TUI’s benefits. I’m bemoaning the lack of imagination that has ended us up here and not in a situation where we can have, say, a small, low-footprint application that can deliver a more structured UI with minimal dependencies. It’s not an impossibility, it’s not even that difficult to imagine, we just don’t have the exact technology.
Yes, but this kind of dashboard was never going to be accessible anyway. It's a dense visual representation of vast system state with constant real-time fluctuation. Even in a browser, it would be hell to navigate the constantly changing state with a screen reader. And visually increasing the scale and contrast defeats the purpose of the density of the original display.
If you need to support screen readers, your UI would have to be totally different: You should allow the user to snapshot the system state and navigate it. Generate succinct summary text to impart the same sense that a dashboard would to a visual user. "Normal: All systems OK" "Critical: Boeing RPA servers down since 2:17PM PDT and 54 others". Once you've done this work, a CLI tool could expose this just as screen-readable:
I’m not just talking about screen readers, though they are important. I mean “accessible” more generally. Yes you could build a specific UI for each kind of user, but that seems far less likely to cover as many uses as building one UI that is structured, programmatically navigable, etc.
> You’re forced to use it exactly the way it was designed and no different
So ... Like all Apple products?
Not even close. Apple UIs - despite recent graphical howlers - have excellent accessibility APIs and are regularly praised by people that track such things. I’ve recently been building a macOS app and the UI testing is also based off it. There are apps that allow full keyboard navigation using it. I do agree that the window management side is much less customisable, though, and that does frustrate me.
I think I see your point. I've had it in the back of my head too.
Guess it's like the separation between backend and front-end. When the logic is neatly wrapped in a nice API you can potentially get a lot of reusability from that since the API can be integrated into other things with other use cases.
But a TUI probably doesn't naturally come with a separate backend. However, if a cli is built in a non TUI way it is about as flexible as a backend. Output can be streamed into pipes etc.
I can't stream k9s output into a pipe or variable but I can with kubectl.
Would be nice if we could have the cake and eat it here. Can TUI frameworks encourage having it both ways?
> They flatten the structure of a UI under a character stream
Isn't this ... everything though? Even the browser which you mention as better in the next paragraph.
No. The browser structures the page in both a DOM tree and an accessibility tree.
They are GUIs --- just minecraft GUIs. One day, we will rediscover why GUI toolkits exist. The only real advantage TUIs have over GUIs is easy remoting, TBH. Maybe that's enough for people. Otherwise? They're just hair shirts.
I've use Claude to make myself a number of little tools and weird apps that only I would want lately. They need to be cross-platform between Linux and Mac and sometimes Windows. The best approaches I've found are Tauri (+Svelte for making layout easier) for lightweight GUIs but for anything more complex I prefer a TUI. The Ratatui framework works very well. A TUI feels like a "real" app as opposed to a glorified webpage. For actually serious software I'd want a native GUI on each platform.
1 reply →
Maybe we just need to go all the way: How about a WASM core with a React GUI that runs inside a custom Electron renderer which outputs the TUI? 100% CPU guaranteed. And you'll never find that important piece of information in an all-monochrome wall of text with no icons. Why use a low-level print() when you could improve your productivity with a high-level framework? /s
Did you reply to the correct post? Can’t see how it follows from mine.
As LLMs consume all our compute resources and drive up prices for the compute hardware on which we run applications, the silver lining is that LLMs are helpful in implementing tooling without a heavy stack so it will run quickly on a lower-spec computer.
I've achieved 3 and 4 orders of magnitude CPU performance boosts and 50% RAM reductions using C in places I wouldn't normally and by selecting/designing efficient data structures. TUIs are a good example of this trend. For internal engineering, to be able to present the information we need while bypassing the millions of SLoC in the webstack is more efficient in almost every regard.
I suspect that a native GUI, or even something like GPUI or Flutter would be still more performant than TUI's, which are bound by the limitations of emulating terminals.
A very important thing about constraints is that they also liberate. TUIs automatically work over ssh, can be suspended with ctrl-z and such, and the keyboard focus has resulted in helpful conventions like ctrl-R that tend to not be as prominent in GUIs.
2 replies →
>would be still more performant than TUI's, which are bound by the limitations of emulating terminals.
That's what makes them great. As opposed to modern "minimal" waste of space UIs or the Electron crappage.
The question is how many decades each user of your software would have to use it in order to offset, through the optimisation it provides, the energy consumption you burned through with LLMs.
When global supply chains are disrupted again, energy and/or compute costs will skyrocket, meaning your org may be forced to defer hardware upgrades and LLMs may no longer be cost effective (as over-leveraged AI companies attempt to recover their investment with less hardware than they'd planned.) Once this happens, it may be too late to draw on LLMs to quickly refactor your code.
If your business requirements are stable and you have a good test suite, you're living in a golden age for leveraging your current access to LLMs to reduce your future operational costs.
Would it be that many? Asked AI to do some rough calculation, and it spit that:
Making 50 SOTA AI requests per day ≈ running a 10W LED bulb for about 2.5 hours per day
Given I usually have 2-3 lights on all day in the house, that's like 1500 LLM requests per day (which sounds quite more than I do).
So even a month worth of requests for building some software doesn't sound that much. Having a local beefy traditional build server compling or running tests for 4 hours a day would be like ~7,600 requests/day
4 replies →
In the past week I made 4 different tasks that were going to make my m4brun at full tilt for a week optimized down to 20 minutes with just a few prompts. So more like an hour to pay off not decades. average claude invocation is .3 wh. m4 usez 40-60 watts, so 24x7x40 >> .3 * 10
Especially considering that suddenly everyone and their mother create their own software with LLMs instead of using almost-perfect-but-slighty-non-ideal software others written before.
I’m not really worried about energy consumption. We have more energy falling out of the sky than we could ever need. I’m much more interested in saving human time so we can focus on bigger problems, like using that free energy instead of killing ourselves extracting and burning limited resources.
They’re also great for reducing dependencies. What used to be a new dependency and 100 sub-dependencies from npm can now be 200 lines of 0-import JS.
I think mc (Midnight Commander) is still one of the best TUIs available - it's very close in capability to the GUI versions (like Double Commander) and it has the benefits of tuis - like that you can run it on a remote system. It looks outdated, but I'm actually now working on a new skin that will hopefully be included in the next release of mc.
Kudos to all mc developers!
I love Claude Code, but how they made the TUI is just plain stupid. Not how it looks, but you know, the React part.
It’s a very cumbersome UI that feels extremely bloated. Especially if you have a lot of text you want to scroll over — eg i want to see the details of the last X exchanges - it just performs absolutely horribly.
It seems like it already was like this from the start, though? I’m not a frontend / TUI dev, but why are these issues so hard to fix?
If the render is already made in JavaScript it makes sense to reuse react as the reconciliation engine instead of building one from scratch.
What is a "reconciliation engine" and why does a TUI need one?
I don't see any real advantage of TUIs over web forms or GUIs for the same thing.
I do like CLIs though, especially the ones that are properly capable of working in pipelines. Composing a pipeline of simple command-line utilities to achieve exactly what you want is very powerful.
There are some applications/systems for which certifying bodies forbid the use of web management because of vulnerabilities in both the protocols and the clients and servers. For example, in my daily, several national cyber organizations (NSA, CSE, GCHQ, etc.) have such direction. That's why our main product line is managed using a TUI accessed at the local console or over SSH (with very, very carefully curated SELinux MAC, among other things).
Having said that....
If one is willing to build one's own HTTP server with integrated MAC, etc., and is able to demonstrate mitigations against known vulnerabilities, one may be able to get the certifying bodies on board. Time will tell.
Yes, this is very niche, but TUIs are in general niche.
I like a TUI when I always want an app to run side by side with a CLI. It’s easier to do split windows in a terminal or tmux/zellij panes than to script two separate app windows to stay locked together as a pair. Although, I’d welcome advice as to how to do it better.
I also find TUIs are easier to program for the same reason they’re limited. Fewer human interface aspects in play and it’s not offensive to use the same UI across OSes. (There are still under-the-hood differences across OSes, e.g. efficient file event watching.)
TUIs work well over ssh. Pretty much everything else is a pain in the ass in some capacity, especially when the ssh client is a smartphone.
Gemini made a lovely TUI for my C# project, but afterwards it said it could just spin up a Kestrel web server inside the app instead which would be a much better solution for managing it, which was fair. (I have a line in my Agents to warn me when I specify a way of building something and it's not the ideal solution)
> I have a line in my Agents to warn me when I specify a way of building something and it's not the ideal solution
And that helps? I tried that a while ago and it very often said this is not a good way of doing something even though it was objectively the best way of doing something. I removed it after a while because it was too random.
In practice, TUIs tend to have good keybindings, & are readily available right in the place where you're running the command (especially for quick tasks).
They can, but don't always. I've used some where you have to smash the TAB key 50 times go move linearly through all the fields and controls. If there are well-implemented navigation keys, yes they it can be very efficient.
TUIs are much easier to run in a container, for one thing. Though, I guess a terminal-based web browser would work for some web apps.
Having a tui file picker in the pipeline can be a powerful technique. Sometimes it just makes sense to have an interface that is slightly more interactive than pre-selecting all the files makes the flow smoother. Being able to put that into a script/alias/whatever is nice.
Other CLI things benefit from this "have a minimal ui interface in the workflow for the one step where it makes sense".
I just added a TUI built on Charm for my custom agent. I primarily use it for two things.
1. Navigating all my chat sessions and doing admin work. It's super fast to push a single key to go in and see what it was about before deleting it.
2. Testing out features and code changes without the web UI / vs code extension complexity.
3. Places where I cannot connect VS Code. I still want to chat and see diffs, a TUI is much easier than a CLI for this.
It also has a CLI, basically three interfaces (CLI, TUI, GUI (vscode/webapp)) to the core features of my personal swiss army knife (https://github.com/hofstadter-io/hof)
Gemini built a nice TUI for me for a DHT scraper project I was coding:
https://imgur.com/a/u3KHbDT
It was like two-shot, cos the first version had some issues with CJK chars.
I was impressed as it would have taken me a bunch of screwing around on lining up all the data etc when I wanted to concentrate on the scraping algorithm, not the pretty bits.
I’d be interested to hear more about your project. I’ve heard about other DHT related things like search engines and such using it, but I haven’t explored the space much myself.
Some of my personal favourites TUI are all over GitHub and there are lots of them to have a look at can be found here:
https://github.com/rothgar/awesome-tuis
https://terminaltrove.com/explore/
Building for Charm, ratatui and many others is really getting much easier than before thanks to AI.
"Building X is easy now"... it was never hard if you had the patience to read docs.
We should be saying "Building X is faster now" instead. But I guess that doesn't induce god complex that effectively.
With Claude, I built a TUI for managing QEMU/KVM VMs (Rust with ratatui.) Solves a lot of problems I had with virt-manager, so I made it a FOSSS project. https://www.vm-curator.org.
Hi everyone, I enjoyed building this TUI for myself and wanted to write down how I did it. I appreciate all the thoughts and feedback! The web app is our main investment, but I think there's a slice of developers who really like to interact with TUIs, so I'm going to keep working on it.
For the demo at https://tui.hatchet.run, to answer some messages asking about it: I built this with the fantastic ghostty-web project (https://github.com/coder/ghostty-web). It's been a while since I've used WASM for anything and this made it really easy. I deployed the demo across six Fly.io regions (hooray stateless apps) to try to minimize the impact of keystroke latency, but I imagine it's still felt by quite a few people.
I haven’t done much with Claude code yet but I’ve watched some rather recent videos of other people leverage it to get work done and I couldn’t help thinking, are we going to end up with a similar UI but with fully deterministic “agents” at the end of this hype cycle.
All of the skills I saw demonstrated were deterministic. So does this end in a Functional Core, Imperative Shell scenario that looks like a Terraform Plan and a search engine-style natural language processor out front?
I never turn down a chance to plug my favourite TUI - jjui, for controlling jj vcs. Life changing combination (and jjui is built with Charm)
https://github.com/idursun/jjui/
Looks great. Curious why not choose Rust and do extension of https://ratatui.rs/?
Yeah, whenever I hear "Building a TUI is easy now" I imagine someone just discovered ratatui.
There are also other frameworks that make it easy to create TUI eg Textual (in Python) https://textual.textualize.io/
I too enjoy the charm TUI libraries, and have been using them to build a settlers of Catan game[0]. And some features are really cool, like different colors depending on dark/light theme.
They have a bunch of functions that concatenate strings, which may not be very efficient compared to using string.builders, but I haven't yet had performance problems.
However I haven't had such a great experience with AI, IMO they're bad at ASCII art.
[0]: https://sr.ht/~vicho/el_poblador/
Indeed. Over a few days of iterations I had this TUI built for fast full-text search of Claude Code or Codex sessions using Ratatui (and Tantivy for the full-text search index). I would never have dreamed of this pre coding agents.
https://pchalasani.github.io/claude-code-tools/tools/aichat/...
If it was so easy Anthropic wouldn't have messed up CC for so long. The author takes for granted the availability of good off-the-shelf TUI libraries for his chosen language.
TUIs are great fun and Claude can make beautiful ones with a little ratatui action super fast. However, the downside of these are that you can't use them with Claude Code so while I have a few I prefer to also have a prompt-response CLI function since that's better for lots of things.
Not sure if this satisfies your requirements, but I've gotten Claude Code to run commands in tmux and view their output (including debugging my NeoVim config), so I think that a TUI is at least accessible, even though it would likely bloat the context window far more than a simple CLI.
Yeah, this is my main way of using Claude Code for anything complex – a REPL or bash window in tmux, and with Claude running commands there. That lets me easily browse through anything that's happened in a UI I'm used to, or manually intervene if needed.
That's pretty nice! It's just the context window problem, yes, but the tmux tip is pretty good nonetheless.
The article talks about this and in fact talks about how one of the advantages of the TUI was that by combining it with `tmux capture-pane` it ended up easier for Claude to use and iterate on, not harder.
Claude Code has done a good job of building a tui MUD client (I couldn’t find one I liked), and then building a GUI version using Tauri where all the config is shared, so you can run it as either a GUI (on any platform) or TUI. Happy with it so far, and I personally use both TUI mode or GUI mode (with floating panes) depending on what I’m doing.
> The Hatchet TUI is not well supported on mobile devices.
Isn't everyone else remoting into a Claude instance on their phones?
Primary driver for me (finally) learning tmux.
Do we want tuis?
I can’t stand Gemmin-CLI. That tui gets in the way constantly
I’m mixed in jj’s tui. It’s better than no ui tho
Mostly tho I’m curious when I’d want a tui. Most of the time in a terminal I don’t want one
I do.
I want my interfacing with computers to be mouseless and TUIs offer that. I don’t think I’ve run into a GUI, no matter how many hotkeys it has and I know, where I didn’t have to reach for the mouse.
CLI only also requires remembering commands, some of which I use very infrequently, thus need to look up every time I use them.
I think TUIs hold a very nice spot between GUIs and CLI.
VS Code with the Vim extension is largely mouseless
I use the TUI from a terminal tab in VS Code, my agent works with that and the custom extension with a webapp based interface, seamlessly and concurrently
GUIs, TUIs, and PR/kanban all make sense in different situations. We'll all use at least two of them on regular basis for coding agents.
TUIs make way less sense for your average user
2 replies →
I just want a stream, not a TUI. If you can't | it it's not real
There’s no reason why you can’t have both.
Well behaved CLI tools have for years already been changing their UX depending on whether STDOUT is a TTY or a pipe.
Have you tried jjui? It’s pretty nice
Big reason why TUIs were popular in the first place is because they are so much simpler to build. Compare ncurses to GTK/Qt, they are completely different leagues. One of my pet ideas is to build a ncurses compatible/style library that skips terminal layer and instead renders directly to Wayland, kinda getting the simplicity of ncurses without dragging all the legacy junk with it.
Yet ironically getting Claude Code to run at 60fps is way way harder in a TUI? Kinda funny that they optimized for "simple" then footgunned themselves into a client that probably took thousands of man hours to get to a reasonable place for power users.
> Yet ironically getting Claude Code to run at 60fps is way way harder in a TUI?
That's what happens when you vibe code your app.
It's just their tech debt. They chose to use react.js in the terminal via ink, and essentially footgun their way through each update.
it's always been easy with ansi... Everyone just thinks it's hard because there's no React for TUI's until recently. '\x1b[' is all you need.
It was good enough for ncurses, it's good enough today.
There are plenty of great tools available these days. Bubbletea would be my tool of choice, I think:
https://github.com/charmbracelet/bubbletea
Charm is what the post submission is using
Charm looks good. What is the TUI library of choice for python these days?
https://www.textualize.io/
The thing with TUIs is that, using mobile native virtual keyboards, it's apparently quite impossible to make them behave in a sane way in browsers!
I think the only reasonable option seems to be reimplementing one yourself, which is massively stupid.
Mobile is not for TUI
More specifically it's an interface designed for a physical keyboard. Or even more specifically it's designed for precise and easy human text input.
1 reply →
Sure it is. I, and millions of others, use it all the time with for example Termux.
1 reply →
If you have a TUI the correct way to support mobile browsers is to 1-shot a React page equivalent. Trying to make the mobile keyboard work for this would be silly.
TUI: Terminal User Interface
> most importantly, they live inline to your code, preventing constant tab switching
No idea what this means.
I think the reference is to all the TUI based coding tools now like opencode.
I think the implicit assumption here is that you are using a terminal-based code editor like neovim... which is not necessarily true.
Building an article is easy now.
Hah.
Were TUIs hard before?
I was working on a fairly niche thing, a library of crossplane compositions written in KCL and thought it would be nice to have a TUI so i could browse through them and see the rendered yaml as claude was working on it. I asked claude code to write it with python and textual and it one shotted it in about two minutes including a test suite.
Dagger has a really nice TUI built on Charm. It reads OTEL to create an interactive tree for your builds and containers. If you have cloud setup, it will also push that all to a webapp interface where you can share and navigate in perpetuity. This works for both CI and local runs, super cool for sharing links to failed builds during dev, even while the dev's local build is still running
https://www.youtube.com/watch?v=EPEGTfaFnpA
The problem with TUI's, that we have all Stockholm syndrom'd ourselves, is that I can't use the mouse cursor to click to the position on the screen and edit the command line.
Emacs vterm can do this. It's the only terminal emulator I'm aware of that can, because it seems nobody else cares. It can even backspace and delete all the text selected.
I’ve built textual tuis (as in the Python library) and it responds to clicks just fine.
FWIW, Plan 9 windows work this way. They are just plain UTF-8 buffers with no typewriter emulation. You can edit any text you wish. If you want graphics, the draw device is a 2D graphics compositor you load assets into then issue rendering commands. Text is a draw primitive and easily displayed any way you want, angled, rotated, moving around, colorful. VT emulation is accomplished by vt(1) which does VT over stdio and emulates an ANSI typewriter using the draw device and it works well. You could even write a Plan 9 native TUI That way, just run it under vt(1). But I would not recommend that - go native.
It is possible. Terminals have supported mouse interactions for a long time.
possible isn't the same as supported and working. A non-terminal hunt-and-peck typer sits down and is presented with a terminal, what's the second that happens when they're typing? they make a mistake and try to click on the word they misspelled, and it doesn't work.
3 replies →
You can use the mouse with TUIs build on the Charm stack
https://github.com/lrstanley/bubblezone
There are a lot of components that resemble things you find in web component libraries
They are! I (well, Claude) built nitpick as a TUI HN client, and it was surprisingly easy to do.
https://github.com/fragmede/nitpick
"Creating garbage is easy now."
It runs poorly, loses keystrokes, and easily gets bogged down with too much terminal input.
I don't want candy coated monospace ASCII graphics. I want something fast and functional. The graphics are _entirely_ secondary. You've missed the point of what a TUI is.
Terminals still have poor keyboard support these days, starting with the Escape key (which should not be ASCII 27 IMO) and various ctrl/shift/alt... key combinations.
[dead]