TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces.
I've been building my own TUI framework [1] and getting amazing results. Good TUIs are more of a GUI than a dumb text terminal.
If we had a cross-platform usable GUI framework, and more consistency across OSes, the story would be different.
RDP works fine but it's based on a full desktop experience. Despite having the technology, we don't have the ability to remote in and run a single graphical program in a single window with the same ease.
We need something as seamless as Parallels for remote remote apps. But I guess we just settled on web apps.
Everyone always acts like GUIs couldn't possibly make HTTP requests, interact over TCP or WebSockets, or do other remote communication. But they're actually, more often than not, more well suited for that than browsers for specific use cases, which are the use cases where you'd desire a devoted GUI.
Every time I use Claude Code, I'm wondering why the hell I'm regressing to the level of a machine. I paste an image that I want fixed, and I don't see the preview of it. I can't cut or edit text somewhere in the middle of a long sentence like in a normal user interface. I can't visualize any helpful graphics, not even Latex. I'm forced to interface like a machine when I'm a human being.
Why can't developers understanding that GUIs and TUIs both have their usage, it just depends on the task?
I'm fine to use vim over ssh into a server, just don't force me to edit fine typography with it.
As far as I can tell, practically everyone arguing for TUIs thinks Claude Code is a horrible example.
Though there’s been some recent progress in alternative models, the fact is native frameworks have some catching up to do. Some in particular (SwiftUI) are downright awful
As a developer outside of that, I love the scratch the itch apps stuff mentioned in here. I have a vibe coded SwiftUI chess repertoire builder app that fits in that same sort of space that I'm currently working on, where I'd probably not have chosen to explore the idea if not for coding agents.
I agree with the article that the terminal is an odd shape which you're fighting against historical specs, etc. The key observation I have though is that the mismatch of terminal apps and libraries to deal with this are all fundamentally built around character cells and cursor movement plus various CSI/OSC/ASC/DEC/xterm/... protocols which are complex and have varying support and interact in weird ways.
To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc.
I know Mitchell Hashimoto has a bit of a different perspective on this, which seems like it's to define some more protocol stuff and continue to build up on things. I think that probably gets to 95% pretty well. But a 100% good is a full replacement.
The New Terminal, the complete break from VT100, is I think the most powerful rebuttal to what I'm saying about TUIs.
My take is that the Morlocks should pack everything that is great about TUIs (and there are great things about them) and move them upstairs to live alongside the Eloi in GUI-land. Let 1000 Bloomberg terminal interfaces bloom.
But there's another even more ambitious take on this, which is to take everything that's pleasant and good about Eloi world and bring it down into the Morlock caves. I don't think you can accomplish that so long as you're drawing interfaces with punctuation characters, but there's nothing to say a terminal has to work that way; you can have a terminal with rich out-of-band-signaled UI. Not just, like, Kitty graphics, but something more like a real terminal that is meant from day 1 to work with all the complexity of a Bloomberg terminal.
You could have had it in 2010, but it's a king hell mess to put together, and you'd sort of assume nobody was going to use it (because it's a break from VT100 compatibility). But that doesn't matter anymore! We are the music makers, &c &c.
I think a lot of very smart people assume we're going to build up from VT100 to something incrementally but significantly better (Ghostty is already materially better than anything I'd used prior). But I hope those people eventually set their sights higher.
Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?
If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham.
Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy experience on Linux, you can use RemoteApps on Windows to have a good remote experience (but almost no other platform), you can use VNC to have an awful cross-platform experience, or you can use a TUI and have all the graphs and interactivity you need over a responsive, low-bandwidth connection on any combination of client+server.
Have you tried to write a GUI program lately? I suspect things may have changed. I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X.
Basically, you write your application on top of a GUI framework that smooths over OS differences for you.
This is hard to square with the continuing obsession with Electron.
I expanded on this point nearby: https://news.ycombinator.com/item?id=49400697
> TUIs run on any OS with minor patches to support quirks
So, which one is it?
I really think they are. The reason for terminals’ ubiquity is precisely their age, and their age results in them standardizing and accumulating bizarre behaviors.
Even in the microcomputer era, standardizing behavior to where it’s literally everywhere someone might want it takes time (e.g. the browser compatibility wars). Re-standardizing terminal behavior is both chasing a way wider (in terms of the number of places folks expect terminals to work the exact same way) but shallower in feature complexity target compared to browsers, and would necessarily be replacing a widely adopted existing standard behavior, not providing something largely novel like the graphical web was. That’s a tall order. I am hopeful for and impressed by the efforts of folks like Hashimoto, but expectations here should be tempered.
TUI that runs on any OS |----------------| TUI without any compatibility mess
In any case we can surely do better than emulating DEC hardware from 50 years ago.
TUIs look bad everywhere, so that's strictly worse
So because TUIs look universally bad, they're better than cross-platform GUI?
qBittorrent looks great on KDE, and would look great on macOS too if they used native icons (I’ve made a theme for that but was too lazy to install it when I was switching laptops). No idea about Gnome and Windows, but probably alright as well.
So, Qt can get you a long way. But you should of course adapt your app to platform conventions and guidelines.
You can't stay engaged if the menus don't bleep and bloop at you and confetti rains down on every click? That's a personal problem. A minimal UI is not automatically a bad-looking UI.
The closest in spirit is Probably something like Dear ImGui[0] and the ecosystem of components and apps built with it, but it's not quite there for me. Something is missing.
good dx, cross platform, fast, not ugly.
pick i dunno 2 or 3.
tui's get to check 2 or 3 of these just like any other gui library. somehow there still isn't a silver bullet here.
now i personally don't build tuis but guake style dropdown simple command and i have some other thing someone made open immediately running in ghostty? hell yea. with that said yes there are some stupid tuis out there that are anything but simple.
You can make slow things with it of course but it's not inherent.
Invent a gui client environment that is universal, works the same way everywhere, over any kind of channel, and is already implimented and supported everywhere, and utterly weightless in all dimensions (ram/cpu/network), and then you might be able to ask that question without it being incredibly ignorant.
Today the closest you might be able to say is web/electron, which is gross on all counts. If anything the closest is X11, which is not remotely close enough.
That's why not just...
I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth.
My approach: Add entries for my localhost apps to `/etc/hosts`, and set up nginx as a reverse proxy.
Now when I go to `http://myapp.local` in the browser, `/etc/hosts` tells it to go to `localhost:80`. The http server sitting there knows which port to send the request to. I also made a systemd service that starts nginx automatically.
Now I have meaningful URLs for local apps, and I don't have to remember which one is listening on which port.
1. In /etc/hosts (or dnsmasq): 127.0.0.1 ourapp.test 2. Caddy in front: ourapp.test { reverse_proxy localhost:8022 }
Caddy auto-provisions local certs, so you get https://ourapp.test, no ugly ports and no "not secure" prompt.
For the overview idea: a tiny local dashboard that scans common dev ports (3000, 5173, 8080...) and lists each running app by name is a ~100-line utility. This is exactly the kind of small tool I build, happy to make a quick version for you.
Malware will thank you.
That same Pi won't even blink at a local TUI.
What do you think of replacing the 'render' part with something that's more like a generic UI? You could keep the UX the same, yet your app would look like a desktop app (or at least close to it).
Trying to fit in the limitations of 80x25 text rendering is cool, but there's nothing in the underlying architecture that of modern graphics display that's predisposed to that, it all ends up as GPU commands.
I'm sure you could get most of the way to what I'm describing with just replacing the font/character set with one that renders things like borders in greater detail.
Hell, you could even add this as post-processing. You look at the terminal output with cellular automata like rules, and try to render UI primitives fitting that.
But in general, going with a fresh new protocol allows you to do a bunch of things semantically that are currently done as pure graphical stuff and that's useful.
At that point you're just inventing a new DOM variant and aren't fundamentally different from any other opinionated GUI framework. The value of the terminal for me is the minimalism. I absolutely despise all these new "features" that get added via protocols. I _want_ the boring grid composed entirely of extremely primitive character cells where WYSIWYG in terms of any underlying abstraction. The only innovation I welcome in this space are improvements to portability and speed.
My snarky response to the author's title would be that you can take your GUIs and all the janky flashing lights they entail and shove them up your ass.
Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, you're just buying another learning curve. Also, the language is Lua (not Rust) so it won't appeal to the ratatui crowd on that front, and there's no proper layout system yet.
Neovim [0] renders to its own buffer system (extmarks, floating windows, virtual text) rather than emitting ANSI escape codes. Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box.
On the UI framework side, morph.nvim [1] provides a React-like component model (h(), state, reconciliation) on top of Neovim. It's not a general answer the way ratatui is, but for the slice of devs already in Neovim (there are dozens of us!), it's a pragmatic way to get GUI-framework-like ergonomics without the terminal protocol fight.
For a sample of what TUIs in this paradigm can look like, I've been working on tuis.nvim [2] (Docker, K8s, SystemD services, process management, and more all as native Neovim buffer TUIs).
+ seamless cli integration + network portable + graphics (!!) with modern emulators + always themable + scriptable + works with any navigation modality + you can copy & paste entire segments of your window easily + easy to consistently theme + did i mention entirely network/os transparent? + blazing fast
tongue-in-cheeck mostly, but i assure tfa, the tui serves useful functions. i spend >80% of my time in terminal, and having a pane to do some task a gui would otherwise be needed for is a sheer blessing. being able to essentially move my session to a laptop is wonderful. no mucking with screen sizes or weird X11 wonkery (if you still use x11). what would blow my socks clean off is a tui/gui+gui/tui backend pair so we can have our tui and you can gui it tooie.
Stop building user interfaces in general. A command line interface is best. If someone doesn’t want to learn how to talk to the computer, they can ask a chatbot to drive the CLI for them.
Edit: the only TUI anyone should be willing to learn is their text editor, vim or emacs, because that’s fine for 99% of tasks.
A command-line interface is a "language" like any other. Each tool has its distinctive keywords, many have complex non-standard grammars (e.g., openssl, ffmpeg). And for more complex tools, the learning curve for this language is hilariously steep. I've been using ffmpeg on and off for two decades and I still feel quite helpless with it.
I think your argument makes sense, but it's just an argument for a standardized language, whether that's GUI, TUI, or CLI. Unfortunately, every other program or class of programs tries to innovate in some weird way. There's no reason why switching from Photoshop to GIMP should be so confusing, but it is.
If you run an emacs server you can connect to it with an emacs in TTY and one in GUI mode.
My life is spent inside terminal and Emacs. Every time I reach for the mouse, I consider it a major fail. Like: big time failure.
Now at times I'll use the mouse: for example when I'm designing a 3D part to then 3D print to fix something around the house. In that case a mouse makes sense. Or for gaming: a mouse makes sense.
But for most of what I do, even just moving my hand away from the home row position to reach for the mouse is a massive fail.
They're an absolute torture to work with over a dodgy connection, which often may not even be your fault. Looking at you AWS.
Here's an example I just pulled out of my shell history:
c=3afba1a; reset; laptop "virtdev ssh liblinux -- git -C liblinux format-patch -1 ${c} --stdout" | tee /dev/tty | termux-clipboard-set
I didn't need to think to write this, I just wrote it right there in the terminal using the shell's line editor, just because I needed it, and it completely solved my problem. It's as easy as pressing up on keyboard now, and I can easily turn it into a script if needed. Nobody had to bend over backwards to add monstruous features to the apps to accomodate me. I knew what my computer needed to do, and I made it do it.
In my opinion we need more of this, not less. More unix and less iphones.
> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.
You're also arguing for CLIs which are absolutely great. But TUIs provide none of the composability of CLIs nor the malleability of GUIs
So while I'm not fundamentally opposed to graphics, I'm absolutely opposed to the "average user" culture surrounding it. I don't care about the "normal person", I don't want "user experiences" that hide the computer, I want all of the computer's primitives exposed so that I have full control.
Except for, you know, every serious professional application ever.
Another example from recent history, I just wanted a easy way to mount all connected drives, so whipped up:
lsblk -l | grep -i part | cut -d " " -f 1 | xargs -I{} sudo mount -m /dev/{} /mnt/{} # automount_all
Meanwhile, a shell alias/function just sits there, easy to see what it does, can control anything in your computer, GUI or not (one way or another), lets you build up your own "database" of tools that all compose together (again one way or another) and finally is easy to put under automated testing.
It’s extra mentioned that CLIs are mostly a good idea but TUIs aren’t.
But I think you know that very well and just wanted to write your little argument to make yourself sound a little bit more of a “unix nerd” as you put it. This little move you’re trying to pull here? Yeah, it’s the HN version of LinkedIn’s humble brag post.
Please, mate. Let’s just not.
I’ve always appreciated the positive side of TUIs and appreciated less the positive side of GUIs. I didn’t grow up with a computer at all and in one of my first adult jobs I had to use a TUI at Papa John’s for punching in orders, it was 20x faster than anything I used after it at other restaurants that were GUI driven (keyboard speed wins for me, fit my brain perfectly). I think I learned it in 5 minutes. I was just a normy trying to pay bills.
I dunno why we gotta be insulting to people’s preferences, the article is genuinely bad about this.
A GUI can be keyboard-driven and as fast as a TUI. The sad truth is that the status quo for GUIs is absolutely terrible, and most were rushed out and not properly tested to check if they're really usable without a mouse.
This is the key point. No platform UI paradigm focuses on keyboard navigability and speed, all focus on mouse and visual effects for discoverability in a pursuit to dumb down the user experience enough to make it usable for everyone, breaking power users in the process (and increasingly also accessibility stacks).
And TUIs are only keyboard driven. So the choice for speed if you don't need graphics is always - TUI (or CLI).
Not so. GUIs absolutely should be keyboard-drivable, if they're written to the human interface specs of whichever platform they're hosted on. That doesn't mean they don't support being mouse-driven or even that mouse isn't the default, but in my experience if the developer has taken any sort of care with the interface then keyboard interaction will be at least as good, if not better, with the keyboard.
> And TUIs are only keyboard driven.
Not true either. There's a line in my .vimrc saying "set mouse-=a" specifically because I want to turn off the mouse in that particular TUI app. If a TUI app doesn't support the mouse they've just not added that support, it's not that it's not possible.
The problem is discoverability. You need to go out of your way to learn shortcuts.
Plenty of TUIs support mouse to various extents too. Claude Code is an obvious example (try the scroll wheel for example).
I agree with you that TUIs are keyboard driven first though - and so you can be certain it will work well.
Absolutely not.
I agree that I found the article to be poorly written. Mainly because it takes a long time to make its point. I didn't really need to see a million examples of the author's vibe coded slop before getting to the topic which the title suggested the article would be about.
Agreed. One would hope the article would go into detail of how to make a great GUI (including tips on how to make sure it’s easy to navigate with a keyboard).
Me: you exist so I can launch iTerm2, Chrome, and VS Code
MacOS: oh, my god
I can't ever imagine using walled garden graphics api in 2026. Particularly for work tooling
I don't want to forward a whole desktop environment just because I want to use a small application I have written for myself.
TUIs are much more portable, easier on eyes, can be information dense, and resistant to lassiez-faire UI library changes on platforms. They don't need GPUs to render, megabytes of RAM to run, great amounts of bandwidth to access from afar.
I'll write a library for the functionality, and will slap a TUI on top. You want a GUI, write it yourself. Everything is GPLv3 licensed. You can do whatever you want as long as you respect the license.
They do these days, because you still need a terminal emulator and those are then basically GUIs in themselves. Ain't the 80s anymore :^)
Most, if not all these systems have Matrox G200 or similar low end 2D integrated graphics which are just there to see the text during boot, nothing else. I sometimes SSH from these systems to my own systems to use TUI or CLI tools.
If I want to go a step further. We have a couple of real VT320s.
Working at a datacenter has it perks, it seems. :^)
It’s ridiculous how far we have fallen behind the Terminal GUIs from the early 90ies. Look at the Turbo Pascal IDE and business apps built with it. Windows, window management, scrolling in windows, rich dialogs. Everything there. While many modern TUIs are just lists with numbers you can select. Everything is pretty rudimentary
I was missing a real terminal GUI library for some software I built. The rudimentary libraries did not work for me.
That‘s why I took Free Vision (the Turbo Vision derivative for Free Pascal) and ported it with the help of Claude Code over to modern Delphi, then modernised the object system and added lots of features and from there we ported it to go.
There are still lots of bugs and oversights (some caused by me not really knowing how original TV worked) that I fix as I go along using it for real projects.
https://github.com/oldwired/fv-delphi-modern https://github.com/oldwired/fv-go
No, I don't think I will :)
It's great for admin tools, alongside CLIs.
It's portable, it's fast, it's discoverable, it has zero bullshit effects, it's as secure as my shell, it's efficient.
And what is this point about agents making it easy to generate GUIs ? They are equally good (if not better) at generating TUIs using any of the great frameworks for this.
Not really?
> it's fast
It's not - most terminals are ridiculously slow, and each TUI framework requires its own hacks to do partial "repaints" using ANSI escapes, because clearing and redrawing the entire screen (yes, just a screen of monospace text!) is unworkable.
> it's discoverable
With no ergonomic way to build a menu bar, display hints/tooltips, or even support modified keyboard shortcuts well across platforms? I don’t think it is.
> it's as secure as my shell
Extraordinarily insecure, in other words.
> it's efficient
As above.
It is, everywhere I need it. Never had to change a single line across the various OS/Terms I used. Can't say the same for web apps or even so-called cross-platform GUIs. Been there, done that.
> It's not - most terminals are ridiculously slow, and each TUI framework requires its own hacks to do partial "repaints" using ANSI escapes, because clearing and redrawing the entire screen (yes, just a screen of monospace text!) is unworkable.
I don't care about these details. I care about the app feeling snappy and responsive. It sure does. Again, I wish it was the case for GUIs.
> With no ergonomic way to build a menu bar, display hints/tooltips, or even support modified keyboard shortcuts well across platforms? I don’t think it is.
Discoverable as in "you can start the app and figure it out along the way without prior documentation reading". And we do have hints, menus and what not. Trying to nitpick ?
> Extraordinarily insecure, in other words.
Are you implying the app running from my ssh session is more exposed than a web app or a API endpoint for a GUI app ?
Like all things, TUI is not a panacea and has its place.