Get the top HN stories in your inbox every day.
gopalv
user3939382
I tried everything to customize the colors of some elements in CC’s TUI, like the dispatched prompt bg/fg, and found it impossible.
A lot of issues that surface for people with colorblindness or adjacent sight issues also arise for eInk monitors.
btbuildem
The more you look into these trendy TUIs the worse it gets -- it's like the developers took the accumulation of all the worst practices since the dawn of programming, and wrapped it all into one unwieldy, overweight, under-performant gelatinous blob that threatens to collapse under its own weight.
MBCook
They’re not terminal UIs.
They’re attempts at pretending to have Windows (etc.) GUIs in a terminal.
Same stuff people made for DOS when Windows wasn’t common or good enough yet.
I’m not surprised they’re a disaster. Or built without understanding the abilities of the terminal they’re running on.
sethaurus
If you don't want people calling these apps TUIs, what would you prefer people call them? And what does the term TUI refer to, if not this?
JamesSwift
ASCII art (or ASCII art interface)
bitwize
Text User Interface.
coldtea
>They’re not terminal UIs. They’re attempts at pretending to have Windows (etc.) GUIs in a terminal.
That's what a terminal UI is, and has been since Emacs was a thing.
dspillett
> They’re not terminal UIs.
Actually, I think that is close to a good name for them: Terminal-based GUIs.
Some are pretty useful, for instance I like lazygit as a simple dashboard/panel for a small repo (or when making small changes to a larger one), some make me wonder what those who made them were smoking!
The less silly ones are handy when you are tinkering with a far away machine and want something a little more interactive than CLI commands and stuff connected by pipes and scripts but don't want to deal with the latency of GUI remoting. Some, though, are so badly thought out that they are slower than using a browser over long-distance X…
MBCook
There are useful ones. Something like Midnight Commander can be way better than lots of manual copy and move commands. The kernel config one is way nicer than the stream style kernel configuration tool. Some of these newer ones are starting to feel more like “text mode bling” than useful.
My objection to TUI is I don’t think it’s clear enough for what’s happening here. I think you could easily argue that applies to most readline style stream CLI programs.
Would you call a fully 3D UI in VR, not a planar in the VR world but true 3D, a GUI? It is graphical by definition. But if you talked to someone about a GUI that’s not what they’d think you’re talking about without additional context.
That’s my objection. I think TUI implies way less than what these programs are doing. Yeah it can describe them but I don’t think it should be the word for them.
elch
em-bee
the first and second are graphics terminals which is muddling up the definition. of course they were called terminals back then until we decided to make a distinction. what they are called is not the point. the point is the distinction. for today's discussion terminal means text without graphics, as shown in the third video.
the real question is why are we still using text terminals?
the short answer is that on remote connections graphics is still a performance issue. in fact the popular solution to making remote graphics performant is webbrowsers. they are the graphical terminals of today.
if i want to build a graphical interface to a remote service, then i build a webinterface.
locally, the answer is historical tools, and that text interfaces are easier to develop and still more efficient to use. but not easier. especially commandline tools without an actual visual interface.
i just had this situation. the dolphin filemanager has a feature to add tags and comments to files. the interface is very clunky. but there is a commandline that lets me set those tags and comments which is much more efficient once you learned how to use that command.
kordlessagain
A shell is the environmental manager, the terminal is the display device, and the window is the container. Add in tabs, web panes and sticky notes + make it all agentic, you get Hyperia: https://hyperia.nuts.services
acjohnson55
I've always been a bit mystified by the popularity of TUIs. To me, the power of the terminal is the streaming model. Composible utilities is something that is much less common in GUIs.
I get it that maybe the constraints of terminals force design of TUIs to be more focused on the purpose of the tool than polish, but it's not that compelling of a point to me.
SchemaLoad
For some basic stuff like vim it works fine. But for almost everything else I'd rather a regular CLI tool or a web interface. I suspect a lot of the popularity comes from people who want to feel like a hacker using 10 terminal windows, but actually want a GUI like experience.
ulrikrasmussen
For me, TUIs compensate for the fact that I can't get good remote GUI rendering on Linux. Yes, X11 tunneling exists, but the experience has always been abysmal for me for anything not hosted on a machine that sits on the same LAN as the client. For Wayland I don't even know if such a thing is possible since I don't think the architecture supports it.
But the terminal is just fundamentally the wrong basic abstraction on which to build a structured GUI, it just happens to require few enough bits to be sent over the wire that it actually works reasonably well over SSH as opposed to pushing graphics.
seba_dos1
> For Wayland I don't even know if such a thing is possible since I don't think the architecture supports it.
Not only forwarding is trivial with Wayland, it also tends to provide better experience than X11 does.
graemep
> Yes, X11 tunneling exists, but the experience has always been abysmal for me for anything not hosted on a machine that sits on the same LAN as the client.
I have used X11 tunnelling to machines on the other side of Europe and it was OK. I did prefer ssh for responsiveness. What happened to NX? What about other remote desktops?
bitwize
[flagged]
xboxnolifes
Obviously people want GUIs. That's why TUIs should be compared to GUIs, not to CLIs. TUIs are nice since you get a lot of the benefits of a GUI, without having to leave the context of the terminal.
yellowapple
I feel like the better solution here (than trying to shoehorn a GUI into an interface meant for text) is to make terminal windows graphically-aware, like how things work in Plan 9.
helterskelter
I dunno, pre-LLM TUI's at least tended to be okay, and keyboard navigation was a first class citizen. Besides, if you were using a TUI instead of a GUI then you basically always ended up saving memory/battery life, and TUI programs are generally more portable than trying to run some ancient GUI program.
I typically prefer CLI myself but having a TUI to manage torrents for instance was much more ergonomic.
kajman
A lot of the complaints in this thread seem like they're aimed more at recent vibecoded UIs than the concept of a TUI.
Like, okay, they are a big step back with accessibility, but they're flickering garbage because they were vibecoded in a weekend and the TS or Python library they're built on was similarly forced upon this world.
SchemaLoad
For almost every tui, a webui works better imo. Most torrent clients offer a web management ui and it's always going to be easier and more feature filled using a platform that was actually designed for it rather than hacking a gui in to the terminal.
bee_rider
Vim is special because 99% of what we do is editing text, and it is the text editor—the importance of that task overcomes the poor discoverability of a TUI. Most other programs should be CLI, so they can fit in the conventional command line toolbox.
zbentley
This. A lot of folks picked it up for that reason when they were young and now are terminal-all-the-things out of sheer inertia.
reissbaker
For the Claude Code / OpenCode / Crush / etc new wave TUIs, it's not about composability or text streaming. It's basically a combination of a few tailwinds:
1. There's already a large-ish community of engineers who live in the terminal e.g. Vim/Neovim/tmux/zellij/etc users. Lots of engineering tasks are accomplished by running scripts in a terminal, so it makes sense for some people to just move as much of their work there as possible. This means there's a set of users you can address with dev tools that run in a terminal.
2. Cross-platform distribution among the platforms most of those people care about — macOS and Linux — is largely a solved problem via package managers. Distributing cross-platform native apps is fragmented at best.
3. Building modern TUIs has become a lot easier thanks to the demand+distribution wins above: there's a lot of appetite for building blocks, and so lots of good options have flourished like Ink for React, Bubble Tea for Go, etc.
4. General developer distaste for the most straightforward analogue to all of this for desktop GUIs: Electron. Deservedly or not it's associated with slow, bloated applications. And if you don't use Electron, doing cross-platform anything is going to be a much harder problem than just pushing out a quick TUI app.
Eventually successful products seem to eventually jump the gap, like Claude Code eventually spawning Claude Cowork and OpenCode adding OpenCode Web. But it's easier and faster to test product market fit for dev tools with a TUI. And plenty of your users will stay there, even after you launch something else.
graemep
You can have more lightweight Web UIs if you just open a browser window instead of bundling the browser with your app as Electron does.
TremendousJudge
While I agree in principle (slack works just fine as a firefox tab, thank you very much), if the application needs filesystem access, it's not going to be viable.
anthk
These were using 66GB compared to what, few KB/MB In NCurses? I can run Nethack/Slashem under a 30 yeard of computer. React it's a joke, and there are ports of Ncurses to any OS.
clan
Totally out of fashion today but think of TN3270. Rather than "streaming" they were forms based and heavily keyboard driven. This could easily be mimicked by a GUI but keyboard shortcuts has become an afterthought.
I still today meet users missing those old workflows. But they express it as "old text interface" aka TUI. If you listen to them you realize they mean blazing fast and shortcut driven. When you work with data entry you care about speed - not animations.
Any beginner likes eye candy. The veteran has stopped caring.
baq
1) TUIs work over ssh without any extra steps.
2) Constraints imposed by the terminal make all the apps look and work approximately the same - in the outside world the standards developed for UX are ignored as a matter of routine just because they can be. TUIs are in an optimum of least surprise, so to speak.
rgoulter
The command line shell has that benefit of piping text between programs. TUIs are runnable from the command line shell. -- So you can get many of the benefits of a GUI (e.g. discoverability) while sticking close to the terminal where you're doing things.
If you're going to "run command, edit command, run command", performing the edits from the terminal you're running the commands in seems reasonable/intuitive. (In contrast, for tools like VSCode, I think it's more common for terminals to take up a fraction of the screen space rather than switching it to full screen. And then developers will say they need a huge monitor).
It also seems to be that keyboard-driven programs are more commonly TUI than GUI. e.g. magit or lazygit. Or lazydocker. Or k9s.
christophilus
I like them because they’re easy to run in a container / sandbox.
coldtea
>I've always been a bit mystified by the popularity of TUIs. To me, the power of the terminal is the streaming model.
Ever used Emacs? Or Vim? Or Mutt? Or Borland's old IDEs?
The power of the terminal is also in ubiquitness, trivial connection to a remote system, and lack of mountains of GUI cruft, that a TUI app can as well have.
acjohnson55
I've used Vim plenty for the past 30 years. I don't prefer it to GUI text editors.
coldtea
Many of us however do.
troyvit
To me, the power of TUIs lies in a few places:
* Lower resource load * Less reliance on a mouse * Related: key bindings for more activities that fit my vi muscle memory * Deeper organization.
Thanks to TUI tools I've been able to roll my own IDE that's invisible when I need it to be (thanks guake & yakuake) and organized by project and tab (thanks zellij). For the mixed role I'm in that works perfectly.
I don't think anybody would look at what I have and call it polished though.
Hackbraten
> This is unacceptable. Closing an accessibility report because the maintainers haven't touched it in months is not “tidying up”; it is hiding evidence. It effectively says that if a bug is ignored long enough, it ceases to exist.
Another perspective from a project maintainer’s point of view:
The people who own and maintain the project get to decide what the status Open and Closed means in the context of a ticket. Users do not necessarily have to agree.
For example, a project maintainer may choose to assign to a status of Open the meaning “this is untriaged or we’re actively working on it”, and Closed could mean “we have looked at this ticket and determined that no team member is going to work on it right now.” In other words, Closed does not have to mean “rejected and this decision is final” but can mean “it’s not something we’re currently working on.” These semantics might not be intuitive for everyone but can be justifiable if they help the project members organize their workload.
__alexs
gemini-cli is not some volunteer maintained open source thing.
Google generally try to be good at accessibility and even publish conformance reports for most of their products https://belonging.google/accessibility-conformance-reports/
hilbert42
I'd agree with this assessment. Moreover, if developers were to stick with the eminently satisfactory CUA (IBM's Common User Access) interface standard and further regularize that then things would be much easier. https://en.wikipedia.org/wiki/IBM_Common_User_Access
If developers want to experiment with various UI configs then let them but keep a CUA in the background that can be called upon by machines and humans alike. (Unfortunately, ergonomics has never been a strong point for developers.)
Lihh27
TUIs were supposed to be the simple option. now they're just web apps wearing a terminal costume
danpalmer
...but without the web's accessibility options, without good text editing, with very basic customisation options, requiring trusted compute instead of working in a sandbox...
They're a long way from web apps, far worse on most axes.
keyle
This is a well documented issue, TUI vs. windows.
Back in the 90s when most SAP systems switched from AS/400 terminals to Windows NT, people reported massive losses in productivity.
I've never worked on SAP, my mother did. And basically, she went from a fully tabular, function-key based oriented workflow, to holding a mouse, moving around and clicking a lot (tabbing and F keys were lost for many functions).
She showed me how she could go from ESC ESC F4 F3 TAB TAB and she was across the whole system a super speed. And this was a terminal, not the actual system!
The short of the story is this
Windows based application work best for discoverability and new users
Terminal based applications work best for faster, memory based navigation and power users.
orbital-decay
That's a problem with the specific GUI, not GUI as a concept. Good GUI frameworks should be built for predictability and keyboard-driven fast paths, and have this included by default so you don't have to make these decisions for each app.
In fact, all successful applications for professionals/power users are built with fast paths in mind. Even Microsoft's ribbon which gets a lot of hate for some reason is an example of that, it's keyboard-driven, customizable, and discoverable at the same time.
chihuahua
In fact, just about everything in Windows (not apps, since those can be created by 3rd party developers who may or may not care, but the OS) can be operated by keyboard: login, start menu, settings, even ancient tools like Event Viewer.
no-name-here
Except, strangely, for setup - if you don’t load your laptop’s touchpad/trackpad driver during the early select a partition screen, you seem to get stuck on later screens like when you are required to connect to WiFi.
baq
There is zero reason this capability couldn't have been preserved in the GUI version. It's a common UX design failure mode when people who don't use and never have used the system are told to design the next version of it, but GUI or TUI has little to do with it. GUI just relaxes constraints (which makes shooting UX in the foot easier!)
array_key_first
Kind of, but one benefit of TUIs is text buffering. Part of the reason you were able to go lightning fast in those old TUIs is your inputs would be buffered and then replayed when the application become responsive. Inputs weren't dropped, so even if you were moving faster than the application could keep up (or the network) it would still function predictably.
This was mostly lost in web applications and most desktop applications. Inputs are dropped and lost during processes, page refresh or navigation. It means that while these applications can sometimes be used with a keyboard, they can't be used reliably or predictably. The same inputs would have different effects based on the time of day or network load.
graemep
It is also almost always less used and less discoverable. To most people using the keyboard in a GUI does not come naturally. It is also an extra effort for developers.
NIckGeek
I don't think the issue is using declarative UI frameworks, it's that the rendering engines these frameworks are outputting to are not taking accessibility into account.
MBCook
I think it’s clear from the article declarative UI could be done, with correct implementation and some options to disable noise.
Clearly no one put thought into any of that. It was just “make terminal, but pretty”.
slopinthebag
Does a terminal even have any accessibility support tho?
paulbgd
The article mentions several TUI programs that rendering in an accessible way for screen readers.
slopinthebag
[flagged]
Spooky23
Totally. I had a colleague who was a pretty awesome programmer and was completely blind. When I first met him, he was working on a braille 3270 terminal. Those IBM terminals were capable of all sorts of stuff.
NewJazz
Yes. Well, for cli yes.
coldtea
>The mythical, it's text, so it's accessible. There is a persistent misconception among sighted developers: if an application runs in a terminal, it is inherently accessible.
Nope, nobody believes that. Devs say that for text documents which is somethig else entirely -- and, with provisions, for terminal single command apps (like grep, cut, ls, and so on). Nobody said it for TUIs.
larodi
TUI will be rediscovered without the window shit. Few people realise it yet, it it’s g. be sprite based as in c64 consoles. Perhaps someone is already doing it somewhere.
Windows and panes… are free to go. The calming environment of text, which as of 2026 is still integral part of humanity’s cultural dna, and is super underexplored in this medium.
I would say the cognitive agression of modern web is more of a nightmare really in the very psychedelic sense of it with all the imagery and video and ads completely devoid of context.
joshka
Mitchell Hashimoto has a great response on lobste.rs https://lobste.rs/s/ifbdw1/text_mode_lie_why_modern_tuis_are...
> It isn't fair to blame TUIs.
> The real problem is that pretty much the whole stack has a terrible AX story.
> First, most GPU-rendered terminal emulators don't engage in system-provided accessibility APIs AT ALL. Because text is GPU-rendered, AX tooling can't "read" it, it just shows up as an image. This applies to Kitty, Alacritty, WezTerm. My own terminal Ghostty is AX-readable (on macOS), and so are others like iTerm2 and Terminal.app (which admittedly do it better than me, we have gaps to fill).
> Second, there are no terminal sequences or initiatives at all for TUIs to communicate AX information to the emulator, so the emulator itself can't do much more than display a blob of text to AX tooling. We need the equivalent of ARIA-style annotations but for terminal cells, runs, and regions. No such initiative exists. Even if TUIs do great things with the cursor, this is going to bite a lot of use cases.
> As an example of combining the above, I've been working on something with Ghostty where we integrate semantic prompt (OSC133) and AX APIs so that we can present each shell prompt, input, and command as structurally significant to AX tooling (rather than simply a text box where the cursor is somewhere else). This shows the importance of the relationship between terminal specs (OSC133), TUIs (which must emit OSC133), and terminal emulators (which must both understand OSC133 AND communicate it to AX APIs).
> The whole stack is rotten. And no one is earnestly trying to fix it (including me, I have limited time and I do my best but this is a WHOLE TOPIC that requires a huge amount of time and politicking the ecosystem and I don't have it, sorry).
Bonus: a simultaneously awesome and horrible reality is that AI is really helping to improve AX here. A lot of AI tooling uses/abuses AX APIs to make things happen. How is OpenAI reading your list of windows, typing into them, etc? Accessibility frameworks! So a lot more apps are taking AX integration a lot more seriously since its table stacks for AI using it... Sad it requires that but the glass half full is more software is doing that.
dgellow
What is AX in this context?
irickt
>> AX originated in reference to UX (User Experience) and stands for Accessibility Experience. AX is also sometimes used as a synonym for accessibility.
The language of accessibility – Staffnet | ETH Zurich https://ethz.ch/staffnet/en/service/communication/digital-ac...
dgellow
Thanks, never seen that acronym
drdec
Accessibility, if I am not mistaken
tim--
accessibility. Also regularly seen as a11y.
rietta
There is no cross platform standard that accomplishes the goals that authors turn to TUIs to solve. There is no widely distributed remotely accessible interface that pops up GUI windows from a shell context that works everywhere.
cmrdporcupine
Sure there is. It's called HTML.
Yes it's gronky.
But so are VT100 escape codes.
Get the top HN stories in your inbox every day.
> The reality is different. Most modern Text User Interfaces (TUIs) are often more hostile to accessibility than poorly coded graphical interfaces.
The Claude Code rendering UI is the first place where I realized the TUI is more like a DOS or Borland UI system rather than a command line interface.
I was poking about CLAUDE_CODE_NO_FLICKER=1 setting when I realized what exactly this TUI is, it is layers of stuff showing up on top of each other with terminal codes.
Ended up reading the Ink Terminal implementation of React
https://github.com/vadimdemedes/ink
Fascinating how it ends up looking Wordperfect or Wordstar from the past instead of pixel based graphics.
The usability for a vision impaired user is about the same, though I remember braille pads for DOS tools (80x25) which work better than all the screen readers which came later.