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.
It rendered perfectly, without JavaScript, in Emacs EWW.
[flagged]
[dead]
> to Commodore 64 level
Thatās unfair to C64 which can smooth scroll very well.
Exactly! The C64 could control where the beam started painting. To move the screen a pixel you just wrote the the x and y offsets to two 8-bit I/O registers. Only after scrolling 7 or 8 pixels you had to copy memory around. I was relatively easy to get this right smoothly and since everything was in sync with the beam it was easy to make tear free.
Shaking effects that did not require memory copy were even easier.
I owned a C64. Remember how buttery smooth the interfaces of those '80s computers were?
Not Apples. But Amigas, omg those were smooth.
I was green with envy, when I saw how fast and smooth a C64 scrolled some text (iirc it was some machine code monitor). My Amstrad CPC464 had no text mode and the Z80A CPU was clearly overwhelmed with shifting the whopping 16KiB RAM of the graphics buffer or even just rendering a line of text.
fewer layers between software and hardware...
Not by repainting the whole screen every frame!
Modern browsers donāt repaint the whole screen every frame either.
Eh, the NES is better because you get two entire screen buffers. The C-64 gives you only one offscreen row or column to repaint every coarse scroll, and the colormap is fixed so you gotta move all of its bytes while racing the beam.
While I agree with your point, I don't understand why you added:
> here's what Gemini says
Surely, if people care to see LLM generated text, they can do it themselves.
It's a clearly marked quote that adds more details. It's perfectly fine.
It's not adding more details in this case, it's adding incorrect information. CSS gradients are rasterized once during paint into a bitmap by the browser. Theres no recalculation going on per scroll unless something invalidates the gradient bitmap, and it doesn't matter how many steps the gradient has or how complicated it is.
The real issue is something was causing the container with the gradient to repaint on every scroll.
Notice how many times Claude Code was mentioned in this blog post nee advertisement?
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).
Yes. Composable GUI is what we're after.
I found this which is by far the closet to what Iām on about. Imagine this but with inline UI controls too (keyboard-controllable, natch), probably based on Nushell (I like Nushell), and maybe an āalternate display modeā type thing for UIs that want to take over more and not act as a transcript. And, no offence, but more visually appealing and implemented with a common-denominator subset of native UI controls where possible. Clearly the issue is not building it, but adoption. I donāt have an answer for that.
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 like TUIs, but if given the choice between a TUI or a CLI program, I'd take the latter. You can always create your own interface from it. Better if it's backed by a library.
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.
I'm with you.
The thing is Windows 98 let you throw up a HTML window with almost zero overhead (the OS used the same libraries) and javascript could get data easily from another process via COM etc.
Now like 25 years later, apparently our choices are shipping bespoke copies of Chrome and Node, OR making shit work on an emulated 1981 DEC terminal. Lack of vision is exactly right.
I think for the time being, there's no way to get around writing native UIs to get a native experience. Any sufficiently high level APIs will have to give up something. TUIs for me fill that niche because across any POSIX-compatible interface they will generally work the same, and modern high level languages make cross-compiling to terminals a breeze. Now to write a native UI across Windows, MacOS, Wayland and X11, that's a different story.
We do. We are only stubborn. Cross platform and low-footprint:
.net core => avalonia ui
Java => JavaFX> TUIs are typically small, low footprint applications
That ship has sailed. These days, TUIs are often Node.js / React monstrosities. Claude Code is a case in point.
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 nowIā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.
>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".
>How many developers are using VSCode? How does that number compare with Emacs/Vim?
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.
> How many developers are using VSCode? How does that number compare with Emacs/Vim?
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.
I agree except about the TUI coolness factor. There really is a lot thatās appealing about TUIs, I agree on that with the other commenters here. I want a better synthesis than what we have.
Buddy, I am here to inform you that you are projecting.
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...
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.
What does ctrl-R do?
>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.
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
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
> Making 50 SOTA AI requests per day ā running a 10W LED bulb for about 2.5 hours per day
This seems remarkably far from what we know. I mean, just to run the data centre aircon will be an order of magnitude greater than that.
Is that true? Because that's indeed FAR less than I thought. That would definitely make me worry a lot less about energy consumption (not that I would go and consume more but not feeling guilty I guess).
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.
I had mc on my $20 second hand 286, there are some newer takes on the classic, ranger and nnn come to mind, support for images on the terminal with sixel is pretty neat!
I had bad feelings on MC, as it's flaky.
Far Manager or Dos Navigator are much better IMO.
Kudos to all mc developers!
I genuinely don't understand the TUI obsession for LLM applications.
Go watch copilot drive VS2026 if you've never seen it in action. There is no way you are going to be able to communicate this same amount of information via plain text in the same amount of time. I can catch a lot of bad stuff mid-flight because I can actually multitask my UI and click into diffs as files are edited in real time.
I don't use VSCode as my editor, but I found out recently you can open the AI agent sidebar as a separate window, and it's been fantastic - it's mostly replaced Claude Code and other similar TUI tools. It's not quite full integration, but the UI is so much easier to use, because you can be more precise. Rather than having a global "more information" toggle that expands everything like in Claude Code or Pi or whatever, I can specifically inspect the bits of information that I'm interested in. There's two parallel subagents running and one of them is doing unusual things? I can explore exactly what it's doing in more detail.
It helps that VSCode has really improved in the last couple of releases - before then, the features available in Claude Code were useful though that it was worth using despite the baggage, and there's still a handful of things I miss in VSCode. But I think the visual information density and acuity that you can get out of a GUI application is far beyond what you can ever achieve in a TUI, and I think as these tools start reaching something like feature parity, that makes GUIs a lot nicer to use.
The reason is simple: the TUI is the fastest way to provide any form of UI over the file system.
Want to do that with web technologies? Youāll need a browser AND a server or build an app using electron or tauri.
I don't disagree. However, the TUI seems to have become the final destination for some major AI vendors. This doesn't look like a stepping stone to me.
I have been wondering where this trend started as well. It's geared towards vibe coders who don't need to see a lot of info.
How fast does it need to be? We're talking about LLMs that run in the cloud here.
Fast as in time-to-market
It's LARPing.
Everyone knows all the best programmers are using the command line firing off one line Awk scripts that look like runic incantations occasionally opening vim to do stuff at blazing warp speed.
So the AI tools people build want to take on those trappings to convince people they are serious tools for grown ups.
Ignore that they are basically a full web stack React/CSS conglomeration - feel the L33t hackerness of 'using the command line'. No IDE like a scrub developer you are using a text console, you are a real programmer now.
Actual hackers will use AWK and anything else... over Acme under 9front which is pretty much graphical, and current Emacs users will use a graphical setup with tons of keybindings, commands and Elisp functions. The best of both worlds. You have both the scriptability, keyboard shortcuts and mouse for selection and quick pointng.
Yeah. I prefer the smarts of Claude code, but the GitHub copilot UI in vs code is much better, especially for previewing ai diffs.
I was (am) excited for vs codes new native Claude code integration, but itās pretty buggy and unreliable.
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.)
> 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.
Did you try some tiling window managers and decided you did not like that?
I prefer most apps to not tile. Tiling window managers might still work with config.
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.
- easy over ssh
- "within bounds" more; designed for actions with keyboard shortcuts and up/down/left/right
- less busy - devs are constrained or less tempted to add animations, css, and other distractions
Gemini built a nice TUI for me for a DHT scraper project I was coding:
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.
What libraries did it use?
"DHT" as is "distributed hash table"?
(That is indeed a nice TUI.)
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.