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).
That’s unfair to C64 which can smooth scroll very well.
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.
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.
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.
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".
How many people eat microwave meals? How many eat gourmet Michelin star dishes?
I don't care "how many use VSCode". My argument Emacs/Vim have great, well loved TUIs. And they are used by a huge number of the most respected coders in the industry. Whether a million React jockeys use VSCode doesn't negate this.
>Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.
Yes, it sells to the masses. Countless food industry scientists aspend many man-hours to develop detrimental ultra-processed crap for a reason too.
Perhaps I'm in some sort of "TUI bubble", but I'd bet good money that Emacs/Vim users outnumber VSCode users by an order of magnitude. But maybe I'm just surrounded by *nix devs.
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 nowGuess 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?
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.
That's what makes them great. As opposed to modern "minimal" waste of space UIs or the Electron crappage.
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
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.
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.
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 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.)
Other CLI things benefit from this "have a minimal ui interface in the workflow for the one step where it makes sense".
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.
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.
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.
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.
https://pchalasani.github.io/claude-code-tools/tools/aichat/...
We should be saying "Building X is faster now" instead. But I guess that doesn't induce god complex that effectively.
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 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.
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
It's also easily mouseless without any Vim or like extension. I never mouse in it, having given intuitive-to-me keychords to all the various moves I need to make beyond the standard stuff.
Well behaved CLI tools have for years already been changing their UX depending on whether STDOUT is a TTY or a pipe.
It was good enough for ncurses, it's good enough today.
No idea what this means.
I think the only reasonable option seems to be reimplementing one yourself, which is massively stupid.
If you wanted to write a shell that has mouse support you could certainly do so, and this would be based on sending escape codes to the terminal to tell it to return mouse events as input rather than let the terminal consume them itself. The shell could then itself support the clipboard if it wanted to, as well as support mouse editing.
I just googled it, and apparently "fish shell" does exactly this, but your hypothetical user is more likely to stumble upon a bash shell which is letting the terminal emulator consume the mouse events and support copy and paste.
https://github.com/lrstanley/bubblezone
There are a lot of components that resemble things you find in web component libraries
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.