Rendered at 03:48:53 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
joshka 3 days ago [-]
As a ratatui library maintainer, NO - please don't stop making TUIs ;)
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.
anon7000 3 days ago [-]
> 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.
Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?
jeroenhd 3 days ago [-]
TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform.
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.
the__alchemist 3 days ago [-]
> TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform.
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.
zahlman 2 days ago [-]
> 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.
This is hard to square with the continuing obsession with Electron.
d-us-vb 2 days ago [-]
I suspect the u ubiquity of electron persists more because maintaining both web and desktop interfaces is somewhat simplified, and as a corollary, you don’t need a separate JS and C/C++/QML team. Qt has gotten pretty good, but JavaScript and typescript are easier to hire.
pjmlp 2 days ago [-]
Pay for cheap labour, get a cheap product.
I thought Claude could do anything nowadays.
bionade24 1 days ago [-]
QML is a Javascript Superset
d-us-vb 13 hours ago [-]
But it runs on Qt, which is most certainly not.
rtpg 2 days ago [-]
I think Qt is a bit different here because of Qt Quick etc but I've tried using "native" GUI frameworks a lot and ultimately the web DOM model is pretty nice for iterating easily.
Querying into the DOM and working off of that means you're not futzing about holding onto a bunch of component references for the one thing you might need later on.
Web layout is also pretty easy to just get right, native GUI frameworks have a different kind of layout model that is not as amenable to "arbitrary" data (at least at first blush).
the reactive programming model also works quite well. While there are native GUI frameworks that lean into reactive programming, they tend to be doing a bunch of weird stuff that cause other issues.
And at the end of the day, when you package something like a Qt app it still often ends up being quite chunky.
In the end tho... the simplest thing is if you do web stack you get a web UI _and_ your "native" GUI in one go. Build things once, not twice. Hard to argue against that when that's presented.
4k93n2 2 days ago [-]
they wont work on android though. thats the main reason i started using more TUIs myself. i needed to be able to run a bunch of python scripts on linux, windows and android/termux. or if any of the linux phones ever matures, or sailfish, then the same scripts will run thereas well, probably without any modifications needed
okanat 2 days ago [-]
KDE has a framework based on Qt's QML that works on Android. It is called Kirigami. They have written apps and even a complete Plasma Mobile using it. The apps work both on Android and Linux.
Mobile has significant paradigm changes that makes using both terminals and traditional GUIs harder anyway though. I do expect the need for completely different cross-platform libraries for mobile UIs.
pjmlp 2 days ago [-]
Termux is not the right way to execute Apps on Android, Pydroid does the job.
Also, Qt does support Android development.
4k93n2 2 days ago [-]
why is it not right? ive been using it for years and everything works just fine
pjmlp 2 days ago [-]
It is trying to fit GNU/Linux into Android/Linux, on a model that has only worked so far because internal politics have prevented the replacement of Linux kernel with Zirkon.
The official NDK documentation on what is supported for NDK written code on non rooted devices, and the hurdles that Termux faces to keep running on standard Android images via PlayStore distribution, show why it isn't right.
pwdisswordfishq 3 days ago [-]
> I think the answer to this is probably to throw all that compatibility mess away
> TUIs run on any OS with minor patches to support quirks
So, which one is it?
Almondsetat 3 days ago [-]
Those two are not contradictory statements
zbentley 3 days ago [-]
> Those two are not contradictory statements
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.
embedding-shape 3 days ago [-]
Maybe not, but they do sit on opposite end of an axis looking something like:
TUI that runs on any OS |----------------| TUI without any compatibility mess
You really can't have both at the same time, either you have great compatibility (which will be a mess), or you don't, to varying degree of course.
Almondsetat 3 days ago [-]
Basically any OS can install any compliant terminal emulator, meaning the cases in which you really have to patch your TUI for another OS are few and infinitely more manageable than GUIs
Arainach 3 days ago [-]
Compliant with what? The proposal is "throw out all the compatibility and build some other kind of terminal" in which case nothing is portable.
TylerE 3 days ago [-]
How so? The idea is you build all the OS specific stuff into the terminal, not into the programs running INSIDE the terminal. Think Infocom Z-Machine, at the ultimate level, although obviously emulating a full on virtual CPU is overkill.
In any case we can surely do better than emulating DEC hardware from 50 years ago.
shevy-java 3 days ago [-]
It depends. If the OS can run e. g. ncurses, you have access to quite a lot of software here, such as htop. Though, I am not sure if it works on windows; but I think it works on OSX. Windows is very strange.
zbentley 3 days ago [-]
That ubiquity is the reason for the limitations of terminals/TUIs discussed in grandparent. Those two are not separable: they’re everywhere precisely because they target the lowest, oldest common denominator (teletype console behavior assumptions from the 1960s).
”GUIs always look bad outside of the "main" platform.”
I think this is slightly wrong in two ways.
i) If you want platform native then reimplement the gui on every target platform. It’s as ”simple” as that.
If you need to ship to multiple platforms then preferably you need lots of plarform specific engineering in any case.
”I just want my hobby tool” scenario likely does not require cross platform support unless there is market for it. I mean rather than offering the tool on multiple platforms it should be offered on multiple languages first, perhaps. As soon as you are not writing the tool for yourself we are talking markets and distribution. Likely most people can chill out and just implement the gui for themselves (and not even publish it in githubb).
ii) cross platform quick-and-dirty way. Without screenreader support, multiple language and glyph support etc.
Game ui:s look the same on all platforms. Websites look the same on all platforms.
There is place and time for deep ui engineering that respects the _critical_ cross platform issues like accessibility (screen readers etc) and different languages and scripts.
And then there is the situation where you want just few images to click. The latter is vastly simpler, fast and fun. But harder to convert to a professional quality gui experience. For small tools and MVPs this sounds like a fair tradeoff.
psychoslave 3 days ago [-]
There is not much difference between a TUI and a GUI once the premise is "let's start from scatch all other again for each applications". Sure then there is no guideline that comes between idea and implementation. But there is also no built-in accessibility, UX best-practices and many specificity of handling a vast experience of building something stable over a large period of time with many feedback from many different scenario.
messh 3 days ago [-]
Html has also some of these properties, targeting the browser. Don't get me wrong. I do like TUIs, they are light weight and compose very nicely with the rest of the terminal (eg tmux). Also, i generally prefer just cli commands over tuis when possible.
eviks 3 days ago [-]
> TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform.
TUIs look bad everywhere, so that's strictly worse
i_am_a_peasant 2 days ago [-]
TUIs would be great if they didn't have to render all text the same size, for me that's the main win with GUIs, you have total freedom with what you can do with your pixels.
I would definitely be pro minimalist unicode-character-themed GUIs for what it's worth. Where every graphical primitive is basically a unicode character, without the restriction on font size.
eviks 2 days ago [-]
That's not total pixel freedom, you're still limited to text
leephillips 2 days ago [-]
Some terminal emulators, for example Kitty, can render text at various sizes (within the same window).
wiseowise 3 days ago [-]
> TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform.
So because TUIs look universally bad, they're better than cross-platform GUI?
notpushkin 3 days ago [-]
> cross-platform GUIs always look bad outside of the "main" platform
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.
Dilettante_ 3 days ago [-]
>So because TUIs look universally bad
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.
WA 3 days ago [-]
No, but I want to click to place the cursor in my 10 line prompt wherever I want. I want to double click to mark words. I want to use a scroll bar. I want to copy paste properly and not "23 lines pasted". I don’t want to read docs to find all keystrokes the TUI supports to achieve what I want.
>I want to click to place the cursor in my 10 line prompt wherever I want. I want to double click to mark words. I want to use a scroll bar. I want to copy paste properly and not "23 lines pasted"
sounds like your terminal emulator is just crap, terminal and iterm on mac just work
WA 2 days ago [-]
iTerm2. Doesn’t work out of the box or something, but I’ll take a look at my config.
maleldil 17 hours ago [-]
> not "23 lines pasted"
If you mean what Claude Code does when you paste longer text, you can just press Cmd-V again to show the full text.
christophilus 3 days ago [-]
It’s trivially easy to run a TUI in a container. Not so much with GUIs. And, since I run as much as possible in containers, and as little as possible on my host machine, I much prefer TUIs.
yencabulator 1 days ago [-]
Wayland runs over a UNIX domain socket you know.
And if you meant "virtual machine" or "cloud" by saying "container", `waypipe ssh myhost`.
pjmlp 19 hours ago [-]
It is as easy as any X Windows or RDP connection.
trueno 3 days ago [-]
there's a million gui frameworks under the sun and i still haven't found one that feels like what everyone has been asking for:
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.
singpolyma3 3 days ago [-]
Except web. Which inexplicably got all of these when no one was looking
pjmlp 19 hours ago [-]
Fast and good DX, not really, unless we are comparing it to command line tools, instead of 4 GL and RAD tools from the 1990's.
Especially when I keep bumping into Electron apps.
TylerE 3 days ago [-]
Not fast.
psychoslave 3 days ago [-]
That depends what is build and how. Granted that a modern web browser is indeed an order of magnitude heavier than an OS, once that ticket is paid anyway, one can built very far, without relying on any additional bloat that contemporary web frameworks puts on top of it. There is not that much more data to send though HTTPS to bring a far more convenient UX than what raw text bespoke tweaks can offer over SSH.
zbentley 3 days ago [-]
Not “not ugly” either. The flexibility is too high and standardization of UX is too low. Technically, we’re missing adoption of default standard toolkits like swing or GTK, and politically a11y/compliance checkers are a far cry from something like the HIG of old.
singpolyma3 3 days ago [-]
How so?
You can make slow things with it of course but it's not inherent.
ziotom78 2 days ago [-]
BearLibTerminal might be something on this line, although its purpose is mainly for developing rougue-like games. It simulates a terminal in a GUI with a high-level API
yeah, something along those lines - but more robustly defined.
barnabee 3 days ago [-]
Agreed. This is exactly what I want, ideally with components and libraries and panels and data shareable and extendable between applications.
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.
charm.sh builds many such things. I love them and their personality.
Brian_K_White 3 days ago [-]
Countless reasons.
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...
crostlybostly 3 days ago [-]
HTML/Javascript would like a word
flossly 3 days ago [-]
we need a way to access locally running web apps without doing an ugly http://localhost:8022 and having to remember that.
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.
iskra 3 days ago [-]
Rather than typing http://localhost:8022, name each app and put them behind one local proxy:
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.
fc417fc802 3 days ago [-]
Won't that be cluttered by various random processes listening via 0/0? Perhaps we need a standardized service that web apps can register with.
antonvs 3 days ago [-]
> I'd say http://localapps should give an overview of all web apps running locally, with links to them.
Malware will thank you.
singpolyma3 3 days ago [-]
Bring back installable PWA on desktop
NBJack 3 days ago [-]
Definitely not weightless. So much bloat has been dedicated to various frameworks for it, and modern browsers are notorious for how much RAM they require. I'm particularly reminded of this each time I try to visit websites on one of my older Raspberry Pis. You are just pushing much of that complexity and overhead to the client.
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.
joshka 2 days ago [-]
> as you're drawing interfaces with punctuation characters
Yeah, in my hypothetical new protocol, the character cell is still there, but it's not the element that drives the main abstraction. The layer above that being more semantic is where the smarts is. So borders, interactive areas, mouse hit mapping to elements, etc. ends up being built into the protocol rather than being a cell level thing. Cells having proper borders being similar to how they allow for underline, being able to have both images and text, ...
I think it's important to do something about the VT100 +kitchen sink stack and to have that as something that still works with that in areas of the new terminal proto. I've got a slopcoded rust library in the works that's about fully mapping the full list of terminal protocols and related things in one coherent library (VT100, ECMA48, DEC modes, iTerm extensions, Kitty, ...). From there I think making that fairly isomorphic with the terminal emulator layer (I have a RIIR ghostty slopfactor there too that fits).
I think ghostty / superlogical looks at this from the perspective of doing pty things and then transfering that calculated state across the wire while doing fun stuff with windows, panes etc. with replay and that sort of thing. I think this is valuable too.
I suspect that there's possibly a way to do a bit of a hybrid on this - normal pty things with the extra sidecar of more semantic structured, but it'll make things more complex for app builders on that side of things.
(On another comment I saw you mentioned "couldn't help noticing how much of the tedious work of putting a TUI together". I think probably textual in python is probably the best of the low ceremony libraries for making TUIs if you haven't checked that out yet. I think someday there will be a good Rust library that has that level of put together-ness. I have some ideas on this for ratatui and have seen a bunch of things that are directionally right for this, but nothing that gets close yet).
fc417fc802 3 days ago [-]
> To get a good terminal UX, ...
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.
joshka 3 days ago [-]
The problem is that cells don't compose well as an accessibility thing. You need a DOM equivalent in order to realistically do a bunch of things that are meaningful at an app level. TUI libraries are all basically doing that DOM thing already - just custom and treating the final shippable product as the cells, positions and imperative instructions for how to tell a terminal what to do. I' just saying that a more declarative interaction is very likely the sort of simple and boring that helps portability (long term) and speed.
fc417fc802 2 days ago [-]
Upon reflection, I think the only thing I'm opposed to is visible "features". As long as the final output remains a dumb grid of cells with extremely limited capabilities I can see where it would be useful for accessibility (or other) purposes to have a bunch of metadata in a standardized format describing the model that underlies the final output. A number of times I've been frustrated by the lack of additional channels when processing streams of data.
torginus 3 days ago [-]
I have a question - I've briefly looked at the API, and it seems like a mostly general-purpose user interfance library.
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.
joshka 3 days ago [-]
If you're redesigning a protocol layer, then I'd say you still want to target fixed size cells as the unit of rendering. It's just not the central abstraction like it is in the current terminal approach. Because you're one step above here, you have th ability to do better border handling. There's a lot a things you miss trying to force borders through a character set thing (e.g. missing characters depending on your font, missing ability to position borders naturally, interaction with background color, adjustment of size and space of rendered text due to interaction with unicode characters and fixed positioning) ...
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.
torginus 2 days ago [-]
I was suggesting something that could be done without changing the protocol itself.
From what I undestand, the terminal is essentially a concatenative text buffer extended with control commands allowing you to move the cursor (pen) to draw more sophisticated stuff, and update UIs.
The logical way to extend this would be to allow genericdrawing commands over the protocol, at which point the whole thing starts sounding like X11.
I'm sure the Unix people at MIT in the 80s saw this as the natural evolution from text terminals to graphics based ones.
Not saying this is a bad idea, but sounds suspiciously like a retread of history.
Or you might want to stop before that, as you suggested, at targeting fixed size cells for rendering, and keeping the console-like UX throughout. I'm sure there's a sensible intermediate step, but if you want to do things like displaying graphs or images (turning the terminal into something that's halfway between a terminal emulator and a Jupyter notebook), it'd be awkward to respect the character grid and the non-square characters themselves.
I'm curious what you think about how far this new protocol should go, and in what direction. You mention 'semantics', as describing behavior, not just what gets drawn to the screen, which neither X11 nor tty does.
joshka 2 days ago [-]
The problem succinctly is when the terminal emulator only sees cell values and instructions it can't do anything more with things. Two really good examples are implementing accessibility well, and scrolling / changing things above the terminal pane without rewriting the whole history.
torginus 2 days ago [-]
What you describe sounds a lot like the HTML/CSS split, with having a separate semantic/display data. I think that's a rather large jump from the 80x25 model, retrofitting that much data sounds like quite the challange.
Not sure how you're planning on doing that, can you incrementally extend the current model, or will it require a completely new protocol?
joshka 1 days ago [-]
New protocol entirely. The existing stuff is too baked as having positioning, movement, cells as the unit of abstraction. You need to have that available, but not as the core abstraction level. The core has to be areas, words, layout, etc. Not: "move to 20, 35, start red, bold, print border characters"
torginus 20 hours ago [-]
Cool, thanks for answering! I don't really want to take any more of your time, is there some place I can read up on this new proposed protocol?
joshka 4 hours ago [-]
It's mostly something I'm thinking a bunch about recently. Nothing written up yet aside from the above. I'd go read Mitchell Hashimoto's Lobsters interview fora different take and see how that resonates with you as well as the recent blog posts about TUIs and accessibility.
fractorial 3 days ago [-]
Damn, what an epic library name.
quantumwannabe 2 days ago [-]
Grok Build uses your library and it has the best TUI of any app I've ever used. It has a lot of features that we take for granted in GUIs like scrollable regions, buttons, collapsible panes, and text selection.
I don't know why Codex and Claude Code haven't switched over; both apps have a terrible UI in comparison.
There's a lot of things you can do to get to 90-95% fidelity with a normal scollable terminal, but that last 5-10% is impossible. And it's because the you're throwing away a bunch of information about mouse movements, clicks, scrolling, keyboard on the input side and all the layout info on the output side (the terminal just sees cells, locations, etc.).
A good analogy is what if your webserver could only send pixels, not html. And receive raw mouse movements. The amount of stuff you have to do to reconcile that across operating systems and hardware would be enormous. That's what you realistically have when you're writing a tool that reimplements all the bits from a terminal emulator in a tui.
chamomeal 2 days ago [-]
I’ve found some of my favorite TUI apps by scrolling around in the built-with-ratatui page. I have always bounced off of rust but ratatui must be a great library!!
internet2000 2 days ago [-]
Not only I want people to stop making TUIs, I want you to stop maintaining your TUI library!
The approach you're describing (redesign the protocol) is one path. Another is to sidestep the protocol entirely by using a platform that already owns its rendering surface and happens to run in a terminal: my preference is Neovim.
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).
I have built a pretty full version of that idea in rust (codex tui2). There's a while tonne of downsides that make it basically impossible to really get to 100% good on this.
> 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.
All that is not true. Take scrolling for example. Each terminal emulator implements this subtly differently (mouse/trackpad/speed etc.), scrolling will never feel native unless you push the control of it into the terminal emulator.
There's more than that, each and every point on this becomes something that you have a gap between native and the terminal emulator that you're building to run in the terminal.
Claude code and gemini have both had various versions of the same idea at times. I'm unsure where they ended up.
jrop 2 days ago [-]
[flagged]
ricardobeat 2 days ago [-]
Hard disagree. Make more TUIs!
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.
I'm very keyboard-driven but I never really got TUIs. A GUI litterly can have just as good keyboard support, but because it doesn't force the user to use it, they rarely take the time to learn it. It's just always tempting to take the path of least resistance.
Especially becuase TUIs doesn't really have any of good properties that a CLI offers such as composebility. It's still a fixed UI with panes and menus which has just been squeezed into a character grid, and now forces the user to learn its pre-set keyboard bindings (which surely can be changed, but with every app having it's own config managment).
It's kinda the worst of both worlds to me. Either go all in and give me a proper text-based interface like Emacs (where you can globally configure how you wanna deal with lists of text in buffers), or just make a proper GUI with good keyboard support.
samspot 8 hours ago [-]
At least with a TUI you know 100% it works with the keyboard. This is not something you can safely assume about any GUI, on the web or otherwise. Our accessibility team is kept very busy by this fact.
t098i3 2 days ago [-]
They made a ton of sense back when the cost difference between a basic text-only terminal and a full-color multimedia PC was significant when multiplied over all of your employees.
hylaride 2 days ago [-]
Yeahs ago I remember when my big bank switched from a TUI front end to a web front end for their front line staff. What originally took a few quick keyboard/tab combinations that was hard wired into employee muscle memory immediately took 2-3 times longer. Fortunately, the need to go into a physical bank doesn’t matter as much, but it’s still a regression…
chiph 2 days ago [-]
I saw the same thing at Best Buy. They switched from a traditional cash register to a web application on a PC. And all the clerks carefully (and slowly) navigated their mice to click on everything.
What was worse was their mouse platform wasn't level. So every time they let go, it would drift downwards and they'd have to go through the "where's my mouse pointer" wiggle again.
api 2 days ago [-]
The truth is that the web is a shit GUI framework. It's slow, clunky, incredibly resource intensive, hard to make uniform, verbose to code. It's terrible.
The way the whole industry adopted it is understandable given the install base, but it's also probably a trillion dollar tax. I'd hate to see how much additional energy is used by billions of end-user devices running a rendering layer that is 100X heavier and more CPU intensive than anything native or TUI.
em3rgent0rdr 2 days ago [-]
Not if you just stick to the basic built-in 30-year-old HTML GUI elements (<button>, <select>, <legend>, <form>, <input>, <table> for layout, etc., maybe also some modern standards like flexboxes) which are very fast, lightweight, east to code, and uniform. The problem to me is every website tries to do some custom javascript monstrosity with their own graphics to keep up with the latest fad. When just sticking to the basics, I find the web is a great cross-platform GUI framework.
ezekiel68 2 days ago [-]
Sure. Except that nobody ever does just stick to those elements.
shoopadoop 2 days ago [-]
You can make a crummy TUI like you can make a crummy GUI...
shimman 2 days ago [-]
eh, I don't agree with this. More like American corporations have degraded the free web to a point where nothing hasn't really improved for the last two decades.
There should be public browsers and public search engines. The private incentives are too much and software built for public needs can be extremely cheaper than their private counterparts once you remove the need to support advertising services.
yencabulator 1 days ago [-]
You can make a bad UI with any of TUI, GUI or WebUI. There's no real reason a GUI app couldn't take the exact same keyboard input as a TUI app did.
Consider this: Grocery store cashier interfaces are graphical these days, yet they're still optimized for fast input.
shoopadoop 2 days ago [-]
Modern TUIs aren't like the form-based TUIs of yesteryear, though!
They're wannabe window managers.
a2ff6eeb0 2 days ago [-]
GUI programs can also use the keyboard.
boredatoms 2 days ago [-]
A lot of us do the vast majority of our non-browser work on remote systems. GUIs are objectively bad for this
okanat 2 days ago [-]
No. When the communication side is actually done thoughtfully, GUIs deliver superior experiences even in remote environments.
VSCode SSH extension is one of the most widely developer-used proof against this. Windows' RDP is the other one where many engineers and POS personnel have experince using them. Many electrical and mechanical engineers still use Windows RDP at my work to run simulations. The connection is responsive enough to survive their home-to-office VPN connection. I set up complex chemical simulation software that is accessed by clients of a HPC cluster over 1000s of kms away.
VScode has a really efficient protocol that communicates only that's required, Windows RDP can declaratively send UI component changes as long as one uses Win32 or WPF. It can also reasonably compress the data to even survive dial-up levels of bad data.
We use multi-attendant video conferencing day to day with whiteboarding extensions. If there is will, efficient and amazing remote-GUIs are easy.
rgzz 2 days ago [-]
Well in plan 9 they work fine remotely so I wouldn't say they're objectively bad.
pjmlp 2 days ago [-]
X Windows was invented on the 1980's and isn't the only way to graphically access remote systems.
Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.
misterderpie 2 days ago [-]
> Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.
Genuine question, what is your alternative suggestion to accessing lower level features then?
A hard time I have with GUIs is that their input/output can't be piped. It's much more cumbersome to try to automate a GUI than to automate something in the terminal.
Whilst I get that this is about TUIs, I do believe there is a reason for shell access due to automation. Good abstractions can be put into the GUI, but I'd argue that you should first build the abstraction, then put a GUI on top of it. AWS is a prime example, any of their APIs can be used w/out AWS Console.
devdraw can be thought of as a 2D rendering engine. You load assets like text, bitmaps and so on then issue draw commands to render them. There is no SSH. Instead you connect to a remote machine and export resources served by your local machine including your keyboard, mouse and display, each of which is a network transparent microservice. The window manager, Rio (and others), multiplexes access to these microservices. You can run a graphical program without a window manager, e.g. you can boot right into Doom or the Acme editor. It's seamless and can run over any pipe that can push 9P including ssh. If you look at the Sam and Acme text editors you will find they are true modern TUI programs.
Shame we had a cloud ready OS for 35+ years and no one noticed. Instead were living in the 60's with GPU accelerated typewriter emulators.
pjmlp 2 days ago [-]
That one was going to be commercial, hence why.
However I would rather prefer its successor, with Limbo for userspace, although probably not Tk as the main UI toolkit.
The terminal thing emulating typewriter are a UNIX thing, as other graphical OSes, presented a plain REPL, or graphical shell, e.g. Amiga DOS did not emulate any tty.
Otherwise I agree with the spirit of the comment.
pjmlp 2 days ago [-]
Use a REPL.
Since when is pipelining a low level feature?
How do you think OSes like Mac OS (the original one), exposed their low level features, whatever that may be?
bmitc 2 days ago [-]
Terminal programs are GUIs. So you are using a GUI to access those remote systems. Thus, there's no reason why another GUI couldn't do the same.
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.
wormius 2 days ago [-]
I'll stick with plain old TTY Consoles, thank you.
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.
bionade24 2 days ago [-]
Of course there is, waypipe, ssh -X, wayVNC on a headless cage (or sway with appropriate config) session.
jayd16 2 days ago [-]
Again, we have the technology but it's not how things are done, usually.
What do you run like that day to day?
bionade24 1 days ago [-]
I use waypipe casually if I have a project on my desktop that I want to work on from my laptop. I even use if I just want to get a Bookmark or Tab from the Desktop PC, since I never bothered to set up any syncing service. Only for nvim I use it's own client/server implementation, it's a bit less latency-affected by the 1%s.
Waypipe is production ready & easy to use. If there doesn't exist a program making use of it for the average user, then it's because nobody saw a it as a solution for any occurring problem yet.
andrewshadura 2 days ago [-]
RDP can do a single app.
chiph 2 days ago [-]
Depends on whether the devs included keyboard accelerator mappings. With the rise of "touch focused apps", it's becoming rare.
vikramkr 2 days ago [-]
Sure but in this case we're the devs. We're in charge of that and would include them if we're making a gui instead of a tui and want keyboard accelerator mappings.
0x3444ac53 2 days ago [-]
Yeah TUIs are great. I'm shit at making GUIs but I was able to slap together a relatively simple TUI for some tooling at work, without any AI. Cheaper, faster, cross platform, less intensive. Most TUI frameworks nowadays have mouse support as well etc. So what if it looks just a little dated?
ordu 2 days ago [-]
I don't use TUI when I can avoid it. I happily use CLI apps, or GUI apps, but TUIs are not here, not there. They lose all the appeal of CLI apps, while getting some weird text interface instead of a polished GUI library and all the possibilities that you can get from rendering pixels, not characters.
When I moved from DOS to Linux, I chuck away TUI file managers and switched to pure CLI and never looked back. I could use GUI file manager, there you can really use mouse, without that jumpy-movements it has in TUI apps. But I wouldn't touch Midnight Commander or whatever.
I tried to run emacs in a terminal. Emacs' support of GUI toolkits is very cumbersome thing. But guess what forced me to abandon this experiment? Emacs is keyboard-driven, and terminals have issues with some keys, while GUI apps can deal with virtually anything.
> If we had a cross-platform usable GUI framework, and more consistency across OSes, the story would be different.
Try egui. I really like it. I'm not sure how much it is cross-platform though, hadn't tried it outside of Linux, but it is really nice. Or if you are an elm-purist then iced might be your choice. Iced lacks on widgets, it has just some basic ones, and if you need something to render a 2d-plot, then you are on your own.
wowczarek 2 days ago [-]
> If we had a cross-platform usable GUI framework
I could swear there once was a (n)curses or otherwise text based GTK+ implementation / backend. It didn't do everything of course, and this was, I don't know, about 2003-2007, but you could compile a GTK application and run it in the console.
I tried finding a link, but unfortunately could not, can't even remember the name, I only remember building a piece of software that way that did GUI or TUI depending on how it was linked.
guessbest 2 days ago [-]
Could you be thinking of libyui, but it was QT and ncurses based. I think it came from SuSE with YaST.
I’ve been enjoying making TUI programs for my own use. It turns out that the Kitty terminal emulator, with its saveable sessions of arrangements of panels that can communicate with each other, is an interesting framework for TUIs:
My big beef is the dichotomy of today's GPU accelerated bit-mapped displays which are burdened with this silly task of running a program that emulates a typewriter. Why TF do we not have a display protocol that can do graphics natively over SSH in 2026?
> TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input.
This assumes a typewriter emulator. Why are we not working on graphical systems where text is a first class primitive allowing us to easily draw text in any color, font, size, formatting and orientation as we please, onto a GPU accelerated display? Keyboard can still reign supreme. No mouse needed but if it is - first class support unlike crappy typewriter emulators.
utilize1808 2 days ago [-]
> Why TF do we not have a display protocol that can do graphics natively over SSH in 2026?
Plan 9 is text first as it was written by Unix programmers who wanted to build an OS and write programs (Rob wanted a better text editor.) It's the OG TUI. Window managers like Rio can run in Rio. You control things by writing textual messages from the command line, scripts, or code, e.g 'echo 100 >/dev/volume' to set audio volume to 100%. Someone wrote a new WM called Lola so I ran Lola in Rio in Lola in Rio because I can. Sam is very much a keyboard driven modern TUI ed (the standard editor). Acme is a mouse driven TUI editor. Both can be automated by programs and scripts. You can edit text while reading your email and chatting on irc from within Acme.
BUT Lots of stuff missing. We don't yet have GPU accel. It's a MSSIVE undertaking. And it has to be carefully designed and would likely be a built around a generalized devcompute kernel device.
hedgehog 2 days ago [-]
It's not hard to make a portable UI framework if you accept similar limitations to the terminal (limited OS integration, accessibility support, etc). You can do anything you want and ship it through RFB.
mawadev 2 days ago [-]
Plus, when you ssh into a server and don't want to or can't rdp it, you at least have more degrees of freedom when you juggle complicated commands, like k9s
01100011 2 days ago [-]
I have old wrists, essential tremor and tics. I try to avoid the mouse where possible. Yes, please make more TUIs!
grepps09 2 days ago [-]
[dead]
63 2 days ago [-]
When you're one of the people who finds TUIs inaccessible, "accessibility" isn't just a downside to be considered, it's table stakes. I think they're fine for one off toys for individuals and small groups, but if you're selling a product to the public, it ought to be accessible first and foremost.
rererereferred 2 days ago [-]
That just means you have a potential userbase for an alternative for non-TUI people. If the market is that big, why not take it for yourself?
VanTheBrand 2 days ago [-]
We should get rid of ramps and handicapped parking at grocery stores too. If it’s such a large market someone can start their own accessible grocery store…
matheusmoreira 3 days ago [-]
No, thanks. I don't want a mere "user" interface, I want a programmer's interface. I don't like the command line because I'm a "unix nerd", I like it because it lets me rapidly cook up little programs and execute them.
Here's an example I just pulled out of my shell history:
This huge oneliner clears the screen, logs into my laptop via ssh, then logs into my development virtual machine, then generates a patch from the specified commit, and this data gets piped into my Termux terminal and my phone's clipboard. Then I paste it into the ChatGPT app for code review.
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.
unchar1 3 days ago [-]
From the article
> 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
matheusmoreira 3 days ago [-]
It's a fine point if made in isolation, but TUIs tend to be more technical and useful simply because they require using a terminal at all. GUIs tend to be made for the non-technical iPhone audience.
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.
> GUIs tend to be made for the non-technical iPhone audience.
Except for, you know, every serious professional application ever.
okanat 2 days ago [-]
Yeah. This is Unix nerd bs and toxic behavior and silly belief that only terminals deliver complex behavior.
I was visiting a radio test lab in last February for our new product. They use a professional software which was written in WPF. The assistant there was flying with the keyboard shortcuts.
I recommend every self-describing Unix or terminal fan to watch videos of photo or video editors / VFX people on YouTube. They are hella fast.
FireCrack 2 days ago [-]
Absolutely true. But the OPs statement is not without merit. While there is a lot of professional software for which GUI is the correct choice, there is also a lot of "GUI slop" which is just a GUI to look good on marketing and to be easier to onboard new users at the expense of long term effectiveness.
messh 3 days ago [-]
If you use the terminal a lot then TUIs keep you there wo the need to manage yet a other window in the OS. For e.g. you can run nvim in another pane in tmux.
israrkhan 3 days ago [-]
Maybe compatibility goes away a with TUIs. But portability, speed, remote access, and less resource usage are still key advantages.
embedding-shape 3 days ago [-]
I agree, authors whole "The time has come to re-evaluate terminal and command line interfaces." is weird, if anything we should be moving MORE towards terminal and command line usage.
Another example from recent history, I just wanted a easy way to mount all connected drives, so whipped up:
How would you even approach this with a GUI? You'd need something like Automator or whatever is called on macOS, then manually pipe GUI elements together (or some other way?), and finally there is no automated way of actually testing that it works, so once it breaks because the inevitable OS upgrade, you'll need to manually fix it. Then whatever solution you came up with or used, is almost never reusable for other things.
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.
croes 3 days ago [-]
The article is not against CLIs but TUIs.
It’s extra mentioned that CLIs are mostly a good idea but TUIs aren’t.
embedding-shape 2 days ago [-]
> The article is not against CLIs but TUIs.
Isn't it against both? Maybe I'm reading it wrong then, because things like these certainly seem against CLIs:
> Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing industry on their shoulders.
> If you haven’t tried your hand at turning one of your 500 throwaway CLIs into a native app, you’re doing yourself a disservice.
Maybe I'm missed something else, but I certainly got the impression the author isn't very impressed by CLIs.
croes 2 days ago [-]
From the article
> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.
singpolyma3 3 days ago [-]
TUIs are not CLI programs though. They're GUIs which render in a terminal
matheusmoreira 3 days ago [-]
The shell's line editor is a TUI. It's a simple text editor embedded right there in the command line. It can even render your shell history by pressing the arrow keys.
singpolyma3 3 days ago [-]
Sure yes. A terminal is a GUI. But it's a GUI used to both run cli programs (which can be piped etc) and TUIs (which cannot)
LudwigNagasena 3 days ago [-]
That example doesn't use any TUI.
matheusmoreira 3 days ago [-]
The line editing in my shell is absolutely an example of a TUI. It's a simple text editor embedded in the command line.
ijcisnfjsj 2 days ago [-]
[flagged]
regularfry 3 days ago [-]
One version of this is "every application is actually a repl with ideas". I do wish the lisp community cared more about GUIs because it feels like there's a huge gap where exactly this sort of extensibility could be merged with precisely the richer sort of visual interaction the article wants.
tescreal 3 days ago [-]
Counter proposal: stop making gui, ONLY make TUI.
+ 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.
bhaak 3 days ago [-]
Emacs does that.
If you run an emacs server you can connect to it with an emacs in TTY and one in GUI mode.
amrit3128 3 days ago [-]
With ghostel, the terminal experience inside emacs has become fantastic. Vterm was acceptable, but still too slow for me. Combine them with packages such as ultra scroll and emacs reader, I'm having.ore fun than ever in emacs
tescreal 3 days ago [-]
Emacs does everything. I want everything to be more like Emacs
DonHopkins 3 days ago [-]
I know, me too, which is why I named my cat Emacs! He's awesome.
TacticalCoder 2 days ago [-]
> i spend >80% of my time in terminal,
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.
bee_rider 2 days ago [-]
TUIs and GUIs are both mostly bad for the same reason, you have to learn a new “language” of interaction for with each program, finding the buttons and figuring out how the designer thought the information should be hidden from you.
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.
matherial 2 days ago [-]
> TUIs and GUIs are both mostly bad for the same reason, you have to learn a new “language” of interaction for with each program ... Stop building user interfaces in general. A command line interface is best.
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.
dbtc 2 days ago [-]
Also ncdu. And *top.
nmz 3 days ago [-]
https://arcan-fe.com/ proves you can have all of that and more without having an archaic TUI.
perching_aix 2 days ago [-]
> network portable
They're an absolute torture to work with over a dodgy connection, which often may not even be your fault. Looking at you AWS.
sjbzbeiks 3 days ago [-]
Tabs vs spaces.
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.
WhyNotHugo 3 days ago [-]
What you're comparing is really "keyboard-driven" via "mouse-drive".
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.
moooo99 3 days ago [-]
> 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).
yencabulator 1 days ago [-]
They used to. OS/2 and Windows both implemented the very keyboard-oriented CUA and focused on that style of use.
I think the real problem is as computers have become more mainstream, they've become more subject to whims of fashion. Consumer-focused companies don't want to be seen wearing last season's UI paradigm. Just watch Apple change things around...
3 days ago [-]
krzyk 3 days ago [-]
Yes, but GUIs are by default mouse driven, very rarely one can see a keyboard driven one (I haven't seen any).
And TUIs are only keyboard driven. So the choice for speed if you don't need graphics is always - TUI (or CLI).
regularfry 3 days ago [-]
> very rarely one can see a keyboard driven one
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.
WhyNotHugo 2 days ago [-]
Keyboard-driven GUIs belong in the realm of a lost art called "accessibility", which enabled people with motor issues (amongst many others) to use applications without a mouse.
FWIW, most of Windows XP's utilities and included software was perfectly usable with a keyboard alone.
cpach 3 days ago [-]
Emacs is primarily keyboard driven.
krzyk 2 days ago [-]
Is there a GUI Emacs? I used only TUI one.
vidarh 3 days ago [-]
> And TUIs are only keyboard driven.
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.
graemep 3 days ago [-]
A lot of GUIs can be muse driven.
The problem is discoverability. You need to go out of your way to learn shortcuts.
JodieBenitez 3 days ago [-]
> And TUIs are only keyboard driven
Absolutely not.
singpolyma3 3 days ago [-]
A TUI is a GUI.
lenkite 3 days ago [-]
A GUI requires a lot more work to be keyboard-driven and as fast as a TUI.
okanat 8 hours ago [-]
No. Maybe web UIs do. However professional GUI libraries like WinForms, WPF, Qt come with a lot of well defined interfaces for activating menu bar, Alt+<key> combos, tab ordering. Just like TUIs, the developer should take time to program them. It is not a lot of work though. Most of the time it is a simple XML config change.
jbstack 3 days ago [-]
I like TUIs for largely the same reasons as you, but I don't think this is actually a valid criticism of the article. It specifically addresses this by pointing out that you can make your GUI keyboard driven if you want to, so this isn't really an advantage of TUIs per se. It just happens that TUIs tend to be keyboard focussed while GUIs tend to be mouse focussed. But that's a design choice rather than an inherent property of TUIs vs GUIs.
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.
notpushkin 3 days ago [-]
> 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).
hombre_fatal 4 days ago [-]
One of the biggest upsides of TUIs over GUIs is that I can run any number of TUI instances.
Meanwhile a GUI's developer has to decide to grace me with the ability to even open more than one window. "A tabbed interface will be sufficient!" -- yay, I'll never be able to view two screens of info at the same time.
WhyNotHugo 3 days ago [-]
TUI developers could implement the same kind of anti-features. This isn't a trait of GUI vs TUI.
c0balt 3 days ago [-]
But they generally don't because it us often expected to be able to have multiple open at the same time, e. G., with lazygit.
brainwad 4 days ago [-]
Opening more than one instance is the default, developers have to actively work to block it. At least on desktop.
hombre_fatal 4 days ago [-]
Which desktop?
It's not true for AppKit, SwiftUI, GTK, Qt, WinUI, or Electron, and I'm not sure what's left.
dunham 3 days ago [-]
Electron requires effort to get single instance. I've had to implement it. You need to call this:
I believe macos is the only OS that enforces single instance by default. If you start xterm five times on linux, you get five independent xterm processes.
tom_ 3 days ago [-]
It's standard for Windows. Double click a .exe, and a new copy loads and runs. If it wants to quit because there's an existing instance running, the code has to arrange for that itself. (It's possible Qt does this for you by default. Depending on the app, this can simplify some things, sometimes! Maybe WinUI is the same.)
It looks like macOS Finder tries to make it difficult to run two copies of a .app simultaneously, so I imagine many programs don't check for this case, but this is Hacker News, so we can use our hacker skills to try and do what they don't want us to: find the exe inside the bundle and run it directly from Finder, or run it from the terminal using its path. (This works for me with Ptacek's mdv app. Two copies of it end up in the dock.)
annapanna 4 days ago [-]
What?
99% of my programs I can open more than one window by just executing the program as normal multiple times, the only ones that enforce a kind of singleton execution are things that also acts as a kind of server, one example is Everything search, but it has a "Open new Search window" for multiple windows.
And that is the default, you have to explicit code in a lock/global mutex thing to block multiple instances.
vscode, electron app, no problem opening multiple windows.
Geany, gtk app, no problem opening multiple windows.
Can you give an example where this doesn't work?
hombre_fatal 3 days ago [-]
Anything from WhatsApp to the Settings app on macOS where I might want to, say, compare the wifi network settings for two access points.
But the point is that the developer has to build the app in a way that lets you do this.
Once again, there is no default with the tools I listed. You decide on how you want windowing to work and then build it.
At this point, show me examples of needing a mutex to "block" a multi-window default.
ksbd-pls-finish 3 days ago [-]
I don't get it. Let's say you create a game.exe, a windows application with a single window. User double clicks on game.exe icon on their desktop, and the window opens. User double clicks the icon again, and the game window opens again. If the developer want to prevent two instances of game.exe running at once, they need to actively detect and prevent this behaviour.
Just like you can start vim several times you can start gvim several times and have a few windows. This is the default behavior, and if the developer wants to change this for some reason, they need to put in some effort.
Maybe macOS is special? I'm not familiar with this platform.
zarzavat 3 days ago [-]
Not on Mac OS, opening more than one instance is undefined behaviour. It may work, but it may also corrupt your data.
okanat 2 days ago [-]
I don't know much about macOS. I only used other people's stuff and navigating it is really hard for me.
You're wrong about GTK, Qt, WinUI and Electron though. They default to "do nothing" which eliminates the ability to even know that another instance exists. You have to manually program that.
orbital-decay 4 days ago [-]
Huh? None of these force single-instance by default
hombre_fatal 3 days ago [-]
They don't do anything by default. The developer makes it do what the developer wants (not the user). You claimed the developer has to "actively block it" which isn't the case.
Even in SwiftUI which has the simplest way to support multiple windows with zero work, the developer has to use WindowGroup, and if they didn't then you don't get to open more than one window.
fc417fc802 3 days ago [-]
You appear to be conflating multiple windows in a single process with multiple processes. The default is that each process is almost entirely isolated from the rest of the running system. You have to actively work to even detect that another instance of the program you wrote is running.
brainwad 3 days ago [-]
The developer (of the app or the app framework) does have to deliberately implement "merging" of a second launched process. The default would be for the two processes to run side by side in both Windows and Linux. It has been that way forever.
The merging behaviour is also in principle possible for TUIs, btw, it's just that nobody does it. But with something like tmux is would be easy to set up that all subsequent calls to your binary actually connect to the already open session launched by the first instance.
orbital-decay 3 days ago [-]
I did not claim it (another user did), but I think your reaction captures the overall sentiment ITT, which is taking perceived status quo as some fundamental thing and defending the worse solution instead of changing the status quo. If all that energy went into perfecting GUI apps the way you want them to work, the ecosystem would have been much healthier. I've seen it in Electron already, and TUI apps are headed the same way, it's simply inevitable. The JS and Python bloat and fragmentation of conventions are already there, reinventing things that used to be simple in a complex way is next (in a way it already happened, e.g. a ton of basic things like hotkey schemes have to be reinvented from scratch each time in TUIs).
hombre_fatal 3 days ago [-]
I don't understand what you're responding to.
TUI apps are multi-instance by default since the user can invoke the program in different pty sessions. The developer would have to actively fight that.
GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window.
Whether things might change in the future isn't relevant because we're talking about how things are today, not speculating about the future. And the time to change one's opinion is when reality changes, not ahead of time based on how you think things hopefully will be.
okanat 2 days ago [-]
> GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window.
I don't know which GUIs you have programmed but for Windows and GNU/Linux this isn't the simplest option. It requires quite the effort to actually enforce single instance.
3 days ago [-]
MintPaw 3 days ago [-]
Why would this be true? The way "single instance mode" usually works is by taking a global mutex or making a lock file. What makes this not possible for TUI apps? Isn't it just culture?
MereInterest 3 days ago [-]
My guess is that is because a TUI can’t give focus to the existing instance. When a GUI application realizes that an instance is already running, it can ask the windowing manager to unhide and focus the running instance.
For a TUI to do the same, it wouldn’t just need to find and focus the window, but would need to trace it through the myriad ways that a TUI can be displayed. I may run a TUI inside a docker container, as part of a tmux session, over ssh. If a TUI somehow managed to focus the existing instance through those layers of wrapping, I would be very surprised, disgusted, and impressed.
So I think it’s that the end goal of “redirect user to existing instance” is infeasible, so nobody bothers to enforce a single instance, since the rest of the steps aren’t possible.
yencabulator 1 days ago [-]
> a TUI can’t give focus to the existing instance
Emacs Server and tmux would both like a word. Make the current tty show the app output.
Mesopropithecus 3 days ago [-]
In TUI, you almost always open a new process when your start a new instance.
Pretty much all GUI frameworks I have worked with behave the same, and you have to actively create singleton behavior.
Then you have Mac OS which makes it hard two create multiple processes of a GUI app. Other OSs don't necessarily behave the same.
globular-toast 3 days ago [-]
On the contrary, multiple windows is normal and the default but tabbed interfaces became popular due to bloated GUI design. This is all down to design and not due to it being a GUI, though.
porridgeraisin 3 days ago [-]
The other thing is, I've had "computer use" on my LLMs since way before they had vision and macos integration. Since in TUIs both control and data is text, they can simply send text to a pty.
There is an opencode plugin for this opencode-pty.
Terminals + browsers is all I want for most apps.
Native GTK/QT is really good, but I only want it for "system" things like a clipboard manager or file manager settings app and things like that.
mike_hearn 4 days ago [-]
Only if the program is designed to be safe to run in parallel. Which can be done with desktop apps too - and they'll run more efficiently as well, as the windows share memory.
hombre_fatal 3 days ago [-]
GUIs have their benefits. You can make much richer UIs with much nicer UX when you're not limited to a grid and whatever paradigm you can hack into the ancient tty stuff, and when you have access to raw keyboard scans.
But I don't think I've run into a TUI that I couldn't have multiple instances of.
arjie 2 days ago [-]
That’s interesting. The browser is also a host of multi-instance applications which makes it a good platform for this. The ChatGPT web app works better with multiple tabs than selecting its in-app sessions in a single tab. Good observation.
Same with numerous copies of image viewers showing the same jpg and txt files
...it's all arbitrary containers and arbitrary recipes to encode and decode binary
fmorel 4 days ago [-]
I hate that you can only have one window of the Windows Settings app now.
underdeserver 4 days ago [-]
But in the article all these GUIs are vibe coded. Tell your AI to allow more than one window. What's the problem?
hombre_fatal 3 days ago [-]
Then you'd have to contend with the rest of the list of TUI advantages over GUIs, like trivially operating them as they run on remote machines.
underdeserver 3 days ago [-]
That is, as TFA mentions, the one good argument.
CamperBob2 2 days ago [-]
That's what RDP, VNC, etc. are for.
They are usually tied to specific user accounts, it's true. But that's something some people made up, and it doesn't have to be that way.
hombre_fatal 3 days ago [-]
Well, it depends on what you want. I'm glad the Claude Code TUI runs in my terminal, for example, because that's where I do software development and interact with the file system and run other lightweight keyboard-driven TUIs that I want to use moment to moment.
Imagine if there were no terminal/pty system. Then what, I'd have to use Claude Desktop (doesn't support multiple windows) and Finder?
So no, it's not the only argument for TUIs.
yencabulator 1 days ago [-]
`waypipe ssh HOST COMMAND` is darn simple.
mihaic 2 days ago [-]
The people that keep arguing for TUIs for everything seem like religious fundamentalists that can't be convinced with any argument that user interfaces should be about the user, and need to adapt to the task at hand.
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.
welwala 2 days ago [-]
> The people that keep arguing for TUIs for everything seem like religious fundamentalists that can't be convinced with any argument that user interfaces should be about the user, and need to adapt to the task at hand.
We are users.
> Why can't developers understanding that GUIs and TUIs both have their usage, it just depends on the task?
Isn't that the case for most TUI apps? They tend to serve quite specific purposes. Nobody writes a WYSIWYG word processor in a TUI. Because you can't and even if you could somehow with sixels it would work horribly bad.
mihaic 2 days ago [-]
> We are users.
In a dual role, I would say that the most impactful aspect (being a developer) matters more.
> Nobody writes a WYSIWYG word processor in a TUI.
But at the same time people write all sorts of other apps that could hugely benefit from a GUI. I seems like if the output itself is not graphical, TUI-enthusiasts won't acknowledge the advantages of a GUI layer, while only bringing in arguments why they can implemented poorly.
GUIs have a much higher surface to be done wrong, so standards are higher. But there's still a decision that needs to be weighed carefully, and many developers seems to simply jump on the TUI bandwagon just because it's easier.
welwala 2 days ago [-]
I don't think a TUI is easier tbh. It's certainly more economical on resources, that's for sure. Really amazing programs running in 35k or so, compared to hundreds of MB for a whole electron stack. The more decent platform native and Qt apps are nicely in the middle but they are kinda becoming extinct. Even Microsoft is just serving us electron slop these days (though they call it something else)
But a TUI needs dedicated understanding of terminal toolkits. That's not easy. A GUI is much more easy mode with electron, a bit of javascript and a GUI toolkit to design the UI, easy peasy. To me the TUI is the hard option.
I really enjoy TUIs though. I wish there was something like vscode in TUI. I like the responsiveness and the no-nonsense. No logos and other commercial bullshit, no huge amounts of whitespace that UX designers consider "best practice", just highly dense data.
Also, I've worked with some of these designers and their holy best industry practices have nothing to do with anything that benefits the user. They're all like: "Is the logo clear enough", "Does the user get drawn to the parts that make us the most money (like ads or premium articles)", "Is the user finding the thing we want to promote".
To me all websites should look like Hacker News does. Not like a "modern" newspaper site does.
zahlman 2 days ago [-]
> The people that keep arguing for TUIs… Every time I use Claude Code
As far as I can tell, practically everyone arguing for TUIs thinks Claude Code is a horrible example.
voidnullvalue 2 days ago [-]
Claude Code should be heavily sandboxed to be used safely. Are you advocating requiring a gfx stack in the sandbox just to use Claude Code?
mihaic 2 days ago [-]
I don't get your argument. Can't you separate your input box from your execution engine?
adastra22 2 days ago [-]
Why would that be?
tptacek 2 days ago [-]
No?
goolz 2 days ago [-]
I honestly get better results out of claude at the command line than inside a GUI. Maybe I am just imagining things. But a lot of times GUIs are just graphical abstractions of TUIs. It is cruft that makes things visually easier and more appealing. That does not stop people from mastering TUIs and unlocking extra potential as they typically offer much deeper customization.
Once you go down this path, it is hard to go back. Very few tasks, apart from things like Photoshop and Revit, really require me to be at a GUI these days. And with MCP a lot of that is going away.
simianwords 2 days ago [-]
I have to agree with this. Ever since Claude Code released I always asked why it had to be a TUI but the sentiment I saw was that it was more powerful for some reason. I never bought that argument.
Now I use Codex UI which is miles better than any other tool I used.
hooch 2 days ago [-]
Sounds like you ought to try Claude Desktop.
mihaic 14 hours ago [-]
I would like that, inside a powerful IDE like the Jetbrains ones though.
starik36 2 days ago [-]
I had the same feeling. I've since been using Claude Desktop and I have the convenience of the UI with Claude Code built right in. It even supports the same commands.
hylaride 2 days ago [-]
I have mixed feelings in this debate, too. The big issue with GUIs is that they’ve become so bloated, especially as the default framework is now often electron apps. Web based frameworks tend to start keeling when large amounts of data need to be handled in the DOM, etc. When I use slack and discord, I sigh when I start seeing UI rendering lag when I switch channels and projects.
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
jjice 3 days ago [-]
The day we get a truly good, native binding, resource efficient, cross platform UI framework, then I will agree wholeheartedly.
I love a GUI in many cases! But if I'm building something, I personally want it across Linux and MacOS at least (personal and work, respectively). TUI answers that problem quickly, easily, effectively, and efficiently.
I'm actually amazed that we have never gotten to a really good UI framework that is cross platform. I really just want something like SwiftUI that's truly cross platform, personally. There are a million arguments to say that we do have cross platform GUIs, but all of them lack in some major way.
dccoolgai 3 days ago [-]
"a really good UI framework that is cross platform."
Just curious re: the obvious example of "The Web" - do you consider it "not good" or "not really a cross-platform UI framework" as such?
jjice 2 days ago [-]
The web is excellent! It loses lots of native abilities though, even as we move forward with file system and USB web APIs.
It's also generally resource intensive, compared to a solid native UI.
I would say that, if you don't need more native control, the web is the best cross platform interface we have, by far. But not having those system API really starts to limit it for certain tasks IMO.
When I just want a graphical utility, I build a single HTML file that includes all of the assets required, and all of the JavaScript so I can run it offline (but generally host them on my site so I can get to them from anywhere). These tools are generally text in and text out that I want a GUI representation for and don't need in the terminal.
jeremyjh 2 days ago [-]
Maybe you should re-examine your priors, because reality is sending you a lot of data that refutes them. If it were feasible to do this, I think it would be done by now. There are a lot of reasons it is very difficult, and while there may be no reason it is impossible, something can become practically impossible when you pile constraint after constraint on it.
One example - wxWidgets exist, and wxDart exist, but getting to something half as usable as Flutter from there is almost impossible. I defy you to even build a layout engine that works on all three platforms. After that, you still have to find answers for theming, spacing, responsive behavior, component composition, inspection/debugging, hot reload, accessibility conventions and on and on.
bayindirh 3 days ago [-]
Sorry, no.
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.
fschuett 3 days ago [-]
> They don't need GPUs to render, megabytes of RAM to run
They do these days, because you still need a terminal emulator and those are then basically GUIs in themselves. Ain't the 80s anymore :^)
bayindirh 3 days ago [-]
I still have quite a few systems which doesn't have a GUI attached to it, and I access them via a pure console.
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. :^)
jimmaswell 2 days ago [-]
> We have a couple of real VT320s.
That's awesome, I have one too and I fell in love with it. I fixed up the old gif320 program to run properly on modern machines a while ago and made a C# port too:
How do you deal with modern programs not respecting TERM/LANG capabilities? I found even using man pages on my machine would sometimes result in the terminal getting caught up on some invalid byte sequence emitted from some unicode that snuck its way through or such.
I ended up writing a program I called VT320 Translator, or vt320t for the name of the binary, which in broad strokes runs your target program in a background terminal and sends curated updates to the VT320 while passing through keyboard input. (You can kind of approximate this with just screen and some other things but it doesn't end up being very good IME) This lets me do some neat things like translate unicode characters into DRCS (Dynamically Redefined Character Set) sequences that you can actually see on the VT320, use optimized heuristics for screen updates tuned to the exact hardware, etc.
At the core is a vtparse-based VT320 emulator that strives to be as accurate as possible with an accompanying diff generator from one emulator state to another. If you're interested I could get into more of what I've done here and even get the code onto my github - it's been private for a while because it's being used in an upcoming game demo but I could easily separate out the non-game-related parts that make up vt320t.
messh 3 days ago [-]
TUIs also live where the rest of the interesting stuff happens, in the terninal. They don't force you to move to a different env
WhyNotHugo 3 days ago [-]
Maybe on macOS you have great APIs, libraries and toolkits for making high quality GUIs, but if you're wanting to write open source software or target open source platforms, your options are limited and poor.
On the Linux/BSD side, most toolkits are of not great quality, you'll inherit all sorts of subtle bugs and quirky behaviours. Most of the software that's of _great_ quality doesn't use the toolkit, but interfaces with the compositor directly. The effort for developing GUIs under such circumstances is dramatically higher than a TUI, and a TUI is usually "good enough".
I really would prefer GUIs for a lot of things. But when a TUI takes a few weeks to make, the equivalent GUI would take a few months to make.
discreteevent 3 days ago [-]
Use Qt or Flutter
WhyNotHugo 2 days ago [-]
Qt is fully of bugs on Wayland, some of which are unfixable because the API makes guarantees that are impossible to uphold. I've reported a few issues upstream where there's no apparent path to fixing them (after years), and have reported countless bugs to applications which are just a bug/incoherency in Qt that can't be fixed.
Flutter is an absolute nightmare to install and work with. Even now the few bleeding-edge distributions where it's available are lagging behind many releases because of the pain that it is to maintain it. I don't want that level of pain as a pre-condition to building my software.
trueno 3 days ago [-]
qt is exhausting. flutter is actually awesome these days but the last thing i want to do is commit to dart
CamperBob2 2 days ago [-]
qt is exhausting
Good luck exhausting Claude. As long as you keep feeding in quarters, it will keep hacking Qt.
JodieBenitez 3 days ago [-]
> Stop Making TUIs
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.
rafram 3 days ago [-]
> It's portable
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.
JodieBenitez 3 days ago [-]
> Not really?
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.
hadlock 2 days ago [-]
I guess you haven't tried ratatui then. All my cli offer a ratatui dashboard mode, and about 50% of the dashboard mode end up as a status dashboard down the road
anthonj 4 days ago [-]
"I built my first serious Mac application"
I will just stop here.
No hates for macs, but your typical cli/tui software devoper is concerned about making their software run on almost anything with an actual os. As soon as I see references to specific operating systems or platform specific libraries my bullshit meter goes off.
I was expecting an article about methology and tooling to develop guis, got an apple fan telling stories about ai use.
anon7000 3 days ago [-]
This is covered towards the end of the article.
anthonj 3 days ago [-]
I only see a bunch of references to swift (very much not portable), but I did skip the Q/A style section. I see he mentions portability, but still no mention of actual portable frameworks.
The word "macOS, "apple" or "swift" appears ~7 times each. No mention to any other GUI framework other than ...a link to the bloomberg terminal website?
I would find the title less misleading if it was "I like swift".
Let say someone, as windows or linux user, clicks on this article claiming he/she should stop "doing TUIs", what take away message should he get from it? "GUIs just looks nice but sucks you have no swiftui"? Personally, I was expecting a developer's angle on GUI programming.
21 hours ago [-]
ta8903 3 days ago [-]
It's only "covered" by saying
>But remember: I’m not really building applications for other people to use. I’m building them for me.
What's the point then? What's the point of writing an entire argument proselytizing towards application developers and ending with saying you're only talking about applications you're writing for yourself?
omnibrain 3 days ago [-]
Yes, stop making TUIs. Make GUIs in Terminals!
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.
Please, don't. One of the main benefits of TUI is being able to freely copy text, I hate opening Textual application and being dropped into this canvas like state.
olejorgenb 2 days ago [-]
A workaround is to use shift + mouse drag to enter terminal native selection mode. (Works in most terminals I believe)
frollogaston 21 hours ago [-]
That's fine until what you need to copy gets extra line-breaks inserted
ChickeNES 3 days ago [-]
Heh, I have one in C23 with Ruby, Python, Go, and JS bindings...may have gone overboard. Not going to publish though until I have dogfooded it enough though :P
intelkishan 3 days ago [-]
Yeah Textual, is pretty good. I have been building a CYOA(Choose-your-own-adventure) game using it
eviks 3 days ago [-]
Looked and see all the same awfulness expected of a textual interfaces where drawing a vertical line is not trivial, so many have gaps instead because they don't know they need a different character
Or where the gaps between elements is huge because your min width is bounded by a char.
Etc.
arxari 3 days ago [-]
Look at the dependencies in the cargo.toml file.
FabCH 2 days ago [-]
I don't really understand this comment. Anything in particular I should be looking for?
swader999 3 days ago [-]
You had me at the name. Love that movie.
cpach 3 days ago [-]
IMHO those screenshots look far from enticing.
I guess it’s a matter of taste ¯\＿(ツ)＿/¯
FabCH 3 days ago [-]
Visual things often are.
I love the visual style. It's especially interesting to set the colour scheme to the orange/yellow glow of reaaaly old school terminals.
Surac 4 days ago [-]
TUI is a kind of self defense. big corps create and kill gui frameworks faster that one can learn them. Browser based ui is a real waste of resources (and also evolve in a absurd pace). The Console is a last resort to write small (understandable) gui that work on many platforms.
no-name-here 4 days ago [-]
Are the TUI apps built on TUI frameworks? Do the TUI frameworks last longer than the gui frameworks you mentioned being quickly killed by "big corps"? In the Windows space, WinForms, WPF, WinUI are likely the biggest examples of gui frameworks, especially from "big corps"; they've been around for decade(s) and have not been abandoned (/ they continue to be supported) - how do TUI frameworks compare? On the other hand, TUIs may be better for things like running over SSH, and for cross-platform compatibility - important, yes. Although for x-platform, things like Avalonia or Uno could be better comparisons?
cbarnes99 4 days ago [-]
Curses, the TUI library, has been around since 1978. It was superseded by ncurses in 1993, which saw it's latest update in December of 2025. Both of them still work and can be used today, with the caveat that the official original curses has been deprecated since 95, but NetBSD maintains an updated version iirc.
underdeserver 4 days ago [-]
They generally stay supported, or if not supported, working.
fp64 3 days ago [-]
I like browser-based UI, as they offer similar advantages to TUIs: You can use the UI on a different machine than the application itself is running. Arguably, modern Web standards also lend themselves to some elegant code design for UI. However, the "waste" is a valid point, but then again your TUI (and many GUIs) will fail on those things that cause the "bloat" of a browser: support for the weirdest encodings, dealing with the most absurd edge cases, supporting the largest amount of devices in a uniform manner. Shipping a whole electron for your crappy app is not what I mean. This should stop, as it trades all advantages for almost only disadvantages.
0x457 4 days ago [-]
Huh? Qt, GTK, Cocoa (AppKit and UIKit), bunch of other linux friendly gui frameworks been around for a long time, even Flutter is still around. What is being killed?
worthless-trash 4 days ago [-]
gtk1/gtk2/gtk3 code will require you shipping gtk(version) on modern linux, not all distros have the legacy libraries.
Apple deprecated carbon (which was a thing when gtk1 was around). I don't think you have an option for this on their ARM hardware.
QT1->N code has the same problem, the older libraries are not shipped on most modern linux.
I do absolutely understand if you're going to do static compiles, that can work around that problem, but that arguement nullifies everything, since you can run/write/execute anything in a turing complete system, if you complain you're just not dedicated enough.
0x457 3 days ago [-]
Carbon was released in 2000 and final release was in 2019. Cocoa, correct me if I'm wrong, was released in 2005. That's 14 years to learn it. Not like you knew Carbon when Cocoa came out because there were like 10 developers making Mac OS X apps before 2007.
y'all are slow learners if that's an issue for you, but React doing major breaking changes at least once a year is totally fine.
frollogaston 21 hours ago [-]
Carbon and Cocoa changed a bunch of times, also React actually makes sense even though it also changed
worthless-trash 2 days ago [-]
you miss the point entirely bro.
0x457 1 days ago [-]
The point is a realease every N years with overlapping year(s) of support is too fast for some?
Shank 4 days ago [-]
Apple believes SwiftUI is the future, not AppKit and UIKit/Cocoa.
0x457 3 days ago [-]
Sure, Apple positions SwiftUI as its primary forward-looking UI framework, but AppKit and UIKit still developed and have access to all API that SwiftUI has.
lenkite 3 days ago [-]
"AppKit and UIKit still developed and have access to all API that SwiftUI has."
No they don't. Many components are SwiftUI only.
throw83949390 4 days ago [-]
What versions of QT and GTK? Running GTK1 or 2 apps is pretty hard. P TUI apps from that era work just fine!
The same reason webui and js is so popular!
0x457 3 days ago [-]
There were 4 (four) major versions of GTK since 1998. You're telling me that rate is faster than you can learn? Maybe you just a slow learner.
ssivark 4 days ago [-]
We're in an era where soon (if not already) it will become straight forward to direct a clanker to move an application from one gui framework to another.
Once we have robust automated computer use, that becomes the verification loop, and this problem will almost surely get solved.
never_inline 3 days ago [-]
> I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful. You see where I’m going with this.
This pretense that the entire value of source code is the "spec" / "requirement" is alarming.
The value of the code is how well-formed the spec is + how well tested it is in the real world. So prompt / mockup cannot replace code.
rhplus 3 days ago [-]
Don’t forget operations and maintenance. You can have a box of vibe coded custom tools and services, but they’re all going to slowly rot as the underlying dependencies - network APIs, platform APIs, auth handshakes, reverse engineered file & DB schemas - change their behaviors and availability.
Sure, an LLM can fix it, but that assumes your original spec sufficiently described the user requirements and wasn’t just a transcript of the original session trying to figure out how how to interface with all those dependencies in the first place.
RunSet 3 days ago [-]
I did see where they were going and that was when I closed the tab.
steve1977 3 days ago [-]
TUIs are really the worst of both worlds IMHO.
The one advantage that a terminal has, is that commands can be concise and scriptable. But that only really applies to CLI.
A TUI is just a poor man emulation of a GUI, without any advantages.
cerved 3 days ago [-]
The advantage is that you can run it in a terminal... So in tmux, over ssh, etc.
steve1977 2 days ago [-]
Why or how is that an advantage over proper GUIs via some remote desktop protocol?
frollogaston 21 hours ago [-]
Latency. My home setup has a different number of screens vs the single virtual display on the headless workstation/instance. I don't want to deal with a Linux GUI shoved into my Mac via screenshare. Linux screenshare host is finicky in the first place. I do lots of stuff via CLIs anyway. I connect to multiple remote instances at once. All those reasons make it easier to SSH.
eloisius 4 days ago [-]
The LLM fetishists really do themselves a disservice with these wild, over-the-top statements about AI capabilities. I’d be willing to bet money that giving Claude a screenshot of part of this blog post would not producing “something useful” for any reasonable interpretation of useful. This reminds me of a line from Peter Diamandis’ Abundance (basically the only thing I remember) that described Google using a “stroke of HTML” to organize the worlds information.
anon7000 3 days ago [-]
It’s extremely easy to try it and find out. No reason to bet money.
akho 3 days ago [-]
A wiki that's somehow not in a browser, a tv remote replacement without obvious keyboard shortcuts, a jupyter lookalike with no editing (as far as I can tell), and two chat interfaces with skills. Good for you, but not like how I use computers.
zorked 4 days ago [-]
Haha, no. For a while, many years ago, it seemed TUIs were indeed on the way out, but then they were relived by the awesome work of people who wrote GPU-accelerated terminals, widget libraries, who extended terminals with more colors and the ability to show Unicode and graphics.
I salute you, heros.
JoshTriplett 4 days ago [-]
You know what's awesome about TUIs? They live in a tab in my terminal. 95% of the time, my system has three windows open: terminal, browser, Signal.
Please, make more TUIs and web apps, so they can live in my terminal or my browser.
walrus01 4 days ago [-]
Additionally, I can with very high confidence run TUI software inside an ssh session to one of my headless machines, and then further within gnu screen or tmux detach and later resume a session with everything I was doing. Even if I switch from my laptop to my desktop, or want to leave a bunch of stuff waiting for a week and come back to it later.
Once you get the key bindings for screen or tmux thoroughly memorized it's very easy.
altmanaltman 3 days ago [-]
Okay but TUIs don't matter here though right? You can easily run GUIs over the web with any box anyway if you wanted to. So how is your headless sever running 24x7 (which is what allows feature you talk about, not tmux or tuis) not the reason you can do that but TUIs are?
I have a windows box that never shuts down and i remote into it and use it GUI mode to do everything you said but with a proper GUI interface. I also use the terminal but your feature (constantly up + resume + multi device) does not need TUIs to even work.
dual_dingo 3 days ago [-]
A server needs a lot more things to have a GUI compared to what's necessary to just run an SSH daemon that offers CLI/TUI access, where SSH is just providing secure network access for the most basic interface the server has anyway (the TTY).
altmanaltman 3 days ago [-]
Okay but the way the comment described their workflow implies they have a pretty solid server where they actually "work". My point isn't TUI vrs GUI, my point is that you cannot say TUIs are better because cloud computing exists. You can easily replace TUIs with GUIs and enjoy the same features that cloud computing provides, so what makes TUIs special? Is it because they are lightweight and don't consume as much resources? That depends on the app itself, there are several lightweight apps that use a web-based secure GUI instead of TUI, so why specifically do you want to be in the terminal?
funlang 3 days ago [-]
Exactly this. Being able to attach to a tmux session over SSH and pick up where I left off is a killer feature for me. No GUI remote solution comes close in simplicity and responsiveness.
8cvor6j844qw_d6 4 days ago [-]
Bubble Tea [1] is my favorite for one-off throwaway stuff in terminal. Wish [2] to make it available over SSH.
Why this is preferable? I would rather have the apps I use represented as a list of apps in my system (drawing on a couple of decades of established UX conventions for how they are displayed and how I can interact with them), the web content I'm reading represented as tabs in my browser, and my terminal sessions represented in my terminal. You present the destruction of this simple separation of concerns as a benefit, but don't explain why it is one.
jauntywundrkind 3 days ago [-]
> You present the destruction of this simple separation of concerns as a benefit, but don't explain why it is one.
And you present the division of this simple unification of modalities as a benefit, but don't explain why it ought be many.
So far it's all just preference.
I'm not going to deny that the terminal has a ramp, is a lifelong learning curve. But I personally find it much more earnest, much closer to what is really happening, with less intermediation, and the way that terminal conposes with other things is usually unbeatable. TUI for humans, jsonl event sourcing for machine-to-machine.
> drawing on a couple of decades of established UX conventions for how they are displayed
I tend to not just click random apps open. I tend to have done some research and found what options there are on my own. I tend to know what I'm looking for, by the time I'm going to run something. In terms of getting there, finding stuff: the best convention I know of is aptitude, and dselect before it. Both very fine very old tui systems, and clear cuts above any app or web store, imo, for its power, directness, clarity, intent, and script ability.
croon 4 days ago [-]
If age of conventions is a valuable metric, TUIs have more. The keyboard hasn't change noticeably, and I can work way faster between separate windows/panes in a terminal and tmux, than in various GUI windows, where mouse focus dictates when I can start inputting.
While a mouse can theoretically use all pixels of a screen, in practical terms a keyboard has a much larger input space than a mouse, and if I can keep both my hands on the keyboard, I can work a lot faster.
At least that's my experience as a (starting) greybeard.
4 days ago [-]
octocop 4 days ago [-]
I was going to post this but you beat me to it. I think we need the folks whom do not enter the terminal to start using it instead of the other way around.
Gud 4 days ago [-]
Don’t be so sure about that..
underdeserver 4 days ago [-]
So you have a cluttered list of terminal tabs instead of a cluttered list of windows.
But with a worse UX?
lelanthran 4 days ago [-]
This is the thing - my window manager can manage windows just fine. I suppose you can make the argument that managing multiple terminals in a tab is a better experience than managing multiple windows in my window manager, but that depends heavily on the terminal being used and the window manager being used.
As a devils advocate in response to all the comments claiming TUIs are fine, maybe consider TUIs mostly do not come with many of the advantages of using a terminal CLI app - you can't pipe data into them, out of them, spawn them and collect the output, etc like you can with the usual stuff you run in a terminal.
IOW, they are a reduced functionality of a GUI - resizing works poorly, scrolling works poorly, UI affordances are poor (sure, you can grey out a button, but drag-n-drop hardly ever works between your various terminal tabs, and the smallest UI element is a full character block, unlike a GUI where you can have indicators that are smaller than a character, mini-windows, etc), lack of widgets, etc.
The lightweight argument is not so good either - look at Claude Code, after all. If you want lightweight GUIs, you can do that too.
The only argument that stands is the ssh one, but if working via a remote connection, I'm not going to want a full functionality application anyway - why would I prefer a wordstar/wordperfect interface to a complex document over a GUI interface? For simple documents, sure, TUI all the way, but when I have multiple panes (outline, minimap, status bars, toolbars, etc), it performs poorly in a TUI.
TUIs are making a resurgence, sure, but only in the context of developers and development.
rpdillon 4 days ago [-]
Whether or not you can pipe information into a TUI is a function of the implementation of it. I've written command line apps that are dual function. When you invoke them with no arguments, they launch the TUI, but when you pass an argument, you can get them to behave like a normal CLI. I don't think this is the norm, but there's no reason it couldn't be more widespread, I don't think.
ghostpepper 3 days ago [-]
Your argument in favour of TUIs is that they can be, in fact, not TUIs and actually CLIs
rpdillon 3 days ago [-]
They can be both!
rpdillon 4 days ago [-]
Indeed, I've been on vacation this week, but wanted to continue working on some of my hobby projects while I'm in the mountains a bit. Being able to use tailscale to SSH into my home workstation and attach to Tmux with my full session of agentic development, server, notes, design, and everything else has been an incredibly fun experience.
Native UIs simply don't have the same flexibility.
Edit to add: I didn't bring my laptop; I'm working from Termux. Surprisingly effective! The code is all in a folder syncing with my phone via SyncThing, so I can try out the sites I'm working on directly on the phone.
eviks 3 days ago [-]
> They live in a tab in my terminal.
So you can't even immediately switch to your app and don't see it in an OS-integrated list?
JoshTriplett 1 days ago [-]
I can see all of my tabs at a glance, their titles indicate what's running in them, and I can easily and quickly switch to them with the keyboard.
boxed 4 days ago [-]
Couldn't you then just vibe code some window manager app that throws a bunch of your stuff into a tabbed window? Seems like the same thing.
walrus01 4 days ago [-]
> Couldn't you then just vibe code some window manager app
My reaction to this is basically about the same as the fictional Ivan Chesnokov
If the point is only that "terminal good because tabs" then that solves that problem
folkrav 2 days ago [-]
I read the point as "it runs in the environment I already use" for everything else, not "there are tabs".
benj111 4 days ago [-]
It already exists. Tabbed by suckless.
orbital-decay 4 days ago [-]
If that's the only justification, a good window manager might turn out to be a lot more convenient.
Terminals are great for CLI. CLI integrated into GUI/TUI is absolutely amazing, but 99% TUI apps do not work like that, they're just awkward crutches foreign to the terminal, so you get no upsides and all downsides. Examples of good CLI integration I regularly use: Kate, Zed, Dolphin, Total Commander, pi. Only one of them is TUI, and honestly it's much worse off with it, since it has to display a ton of formatted text and sometimes pictures. It's really inconvenient and just looks like cargo cult rather than a necessity.
benj111 4 days ago [-]
>or my browser
But then a load of others will complain about electron apps.
Further you then have an os within an os. You need to remember to look in your bookmarks, not your start menu. And you're basically throwing away the window manager too.
JoshTriplett 3 days ago [-]
> But then a load of others will complain about electron apps.
I want to run web apps in my browser. I understand why Signal isn't a web app, and I'm willing to put up with that for security, but nobody else gets that excuse. Web apps belong in a browser tab.
thomasfromcdnjs 4 days ago [-]
I built "ssh sshfighter.com" recently, enjoy!
fragmede 4 days ago [-]
Mine's funky.nondeterministic.computer
thomasfromcdnjs 4 days ago [-]
So great =D
hollerith 3 days ago [-]
I used to work like that (minus the Signal window) and have no desire to go back.
AtHeartEngineer 4 days ago [-]
and music
zmmmmm 4 days ago [-]
Make more TUIs ....
The main thing I like is that TUIs are guaranteed to be navigable by keyboard. So many non-TUI apps don't include shortcuts at all for critical actions. It makes the first week of using the app more efficient and the entire rest of your life less so. Add on to that, I can probably run a TUI on my server. Or my cloud instance. And in my sandbox. Over SSH.
So: do make TUIs and bind their keys to Vi-like shortcuts as much as possible and I will use your app every time over a GUI app.
Pro tip for Mac users - install Karabiner and bind right-Alt + jklm to cursor movements. Immediate VIM navigation through the whole OS.
benj111 4 days ago [-]
>The main thing I like is that TUIs are guaranteed to be navigable by keyboard
I don't disagree with you, but in ye old days you had guis that were navigable by keyboard.
And these were discoverable. That one program you use every day, you can spend the time to learn the short cuts. You can still get things done by clicking around though.
I suspect the underlying issue is one of limitations. Terminals are limited in what they can do. Guis and the web, you can do so much more, so people do.
I think another issue is touch screens. Guis and the web have moved to optimise for those. It decreases information density, forces a move away from the old standards to new much weaker ones. Tuis can't really do touch, so they don't have to make those tradeoffs.
CalRobert 3 days ago [-]
Mnemonics made keyboard shortcuts obvious but they’re basically dead now. Holding alt sometimes reveals them.
gr_norm 3 days ago [-]
Agree with the rest of the comments here: keep making TUIs. Fully keyboard-driven, compact interfaces that live in my terminal with the rest of my CLI devtools are the best!
cpach 3 days ago [-]
This makes me curious. What are your favourite TUI applications?
The only one I use is Copilot (inside of a VM). ALl other applications I use are GUI/CLI/webapps.
frollogaston 21 hours ago [-]
Vim and Tmux. Does psql count too? I'm not really a fan of TUIs aside from that, most stuff is just CLIs.
Claude etc do make sense as TUIs too, but I don't like they way they were implemented. They mess with basic terminal features like copy/paste or scroll when there's no reason to. And they're somehow heavier than actual GUIs.
folkrav 2 days ago [-]
Not OP but, I regularly use :
- yazi as a file explorer
- lazygit for git
- tmux/zellij as multiplexers
- fzf left and right for a bunch of utils (terminal history, switching between projects in zellij/tmux when working in multi-project workspaces, etc)
- neovim as a text editor
- glow for markdown reading
- currently on pi for my home harness, CC at work
I'm probably missing a few but those are the ones I use more or less daily.
PaulRobinson 4 days ago [-]
Yesterday I was flipping between some TUIs, native apps, web apps and an electron app. I think it was only because I was trying to do a lot in each of them I became really aware of the latency lag in some of these.
There are real advantages of TUIs: less CPU; sometimes I want to be using a personal TUI on a personal dev server quickly from a work laptop at lunchtime and an ssh + tmux + TUI is perfect; most modern TUI libraries are significantly less painful to work with than most modern web app frontend libraries; I can change the font size of my terminal easily if I need to, more easily than native (but not web app). But by far the biggest, is they just generally tend to be very fast and responsive compared to everything else.
codethief 3 days ago [-]
> I think it was only because I was trying to do a lot in each of them I became really aware of the latency lag in some of these.
While I get your point, a lot of vibe-coded agent TUIs (Claude Code, GitHub Copilot CLI, …) aren't exactly fast, either.
jbstack 3 days ago [-]
A lot of vibe-coded GUIs aren't fast, so this particular issue changes nothing. You're describing a property of the software development method, not TUIs vs GUIs.
krzyk 3 days ago [-]
Benefit of TUIs is that sometimes they are extension of CLI.
Sometimes I can use `du` to check what uses so much space, but sometimes ncdu is better for me.
And the best part - I can use both when I ssh to another machine, using the same command line, without thought. While GUIs need added thought, to switch from CLI to GUI on the remote one would need to use a different interface, or have X11 forwarding on (which is also a good option) and x11 libs on the other side.
Or use some other connectivity. ssh is simple, works on most servers I have access to.
vidarh 3 days ago [-]
> And the best part - I can use both when I ssh to another machine,
Exactly. I'm currently on vacation and has checked in on long running Claude Code sessions over ssh every few days. I could have used X11 forwarding or VNC if I needed a GUI app, but the connection I'm on is currently slow and unstable, and using text mode has been far more palatable, especially since I can use tmux (or in the case of Claude Code, just using "claude agents" and let it background the sessions itself).
blipmusic 3 days ago [-]
Keep making TUIs. Keep making whatever you want. These "terminals weren't made for that" kind of comments are a bit tiresome. I can run TUIs on machines I only have ssh access to and they are often leaner than the corresponding GUI variant - though perhaps less so with today's fancier TUIs. 'top' has a TUI and isn't exactly new, some interactivity - yes, even in a terminal - can be nice.
I'm currently trying to create a GUI version (immediate mode library) of a CLI tool of mine and it's mostly a shit show and three times the work of a data-in-data-out CLI tool. Good learning experience, though. I should note that I don't care whether the GUI version has a "native feel" or not (if you have the time to do so, be my guest), only whether it's functional and reasonably fast, since otherwise that's even more work for an open-source tool. Though, when I undoubtedly make the more interactive TUI version later on (ratatui just seems too nice not to try! :-)) it will probably bring a similar complexity development wise.
Then again I'm not into agentic coding at all so maybe the joke's on me. On the other hand, at the moment I need to learn about the data I'm processing, the GUI library/framework I use, and being able to help the people I work with troubleshoot the equipment that collects said data. I'd miss out on most of that if I coded by prompt. Perhaps I'll try later, perhaps not.
Keep making TUIs, or GUIs for that matter.
petesergeant 3 days ago [-]
I’m absolutely into agentic coding and you’re still right. A TUI can live easily in a tmux window on a machine I can SSH into from my phone. Also: yes, you can vibecode a UI, but the author’s point reduces to absurd conclusion that you shouldn’t write and distribute any software at all.
israrkhan 3 days ago [-]
TUIs, work on several operating systems. I use same set of apps across Mac, windows and Linux.
You can use them remotely over SSH connections, and they can survive disconects (within tmux). No VNC, or X11 forwarding needed.
They take less memory. compare vscode vs nvim.
Super fast to launch.
They can integrate with other TUIs and shell apps, shell-scripts, pipes
and lastly they do not contain Ads. lol
self_awareness 4 days ago [-]
Do more TUIs.
People are unable to do good GUIs. The web shows this; completely disregarding any UI guidelines by web people established since 80s is a proof that most people have no idea how to make GUIs.
I don't know how to make a good GUI. That's why I need good templates and strong guidelines, discipline and spend long time on design. Most people don't do that.
TUI is much, much easier. It's also possible to do bad TUIs, but it's easier to do a good TUI than to do an average GUI.
ncr100 2 days ago [-]
Personally, I don't like being told what to do in a title. And personally, my hackles raise when that's combined with in-group jargon.
Intentional or not, the rhetorical style of the title, plus the subtitle opening on the word "weird" before it's defined, has an ostracizing effect on me. I guess that it could have an ostracizing effect on others, though I can only speak for myself.
inatreecrown2 3 days ago [-]
The nice thing about TUIs is: they are platform independent. Whereas with SwiftUI apps you are bound to macOS.
raincole 3 days ago [-]
TUI apps are only platform independent if you make them so.
GUI apps are only platform independent if you(r framework) make them so.
It's a quite common illusion that TUI apps are "automatically" platform independent. Even knowing which terminal emulator intercepts which shortcuts and how they handle width change, control character, mouse events, images, etc and design around them is not a trivial task.
On the other hand, making platform independent GUI apps haven't been easier. Just use Electron. Yes, performance blahblah, but thousands of Electron apps work on millions of machines just fine.
dzikimarian 3 days ago [-]
They don't work fine. I run lot's of TUIs because they are snappier. You may bury this problem with money buying 64gb laptop, but that facade falls as soon as you launch local LLM and discover there's no space left for Spotify.
raincole 3 days ago [-]
Believe or not, millions of programmers (presumably the most tech-savvy demographic) use VSCode for their daily job.
dzikimarian 3 days ago [-]
Because it currently has best support for their stack. Being tech-savvy means also you understand, you can't move entire plugin ecosystem of vsc to notepad++ and call it reasonable.
hadlock 2 days ago [-]
MacOS: what is my purpose
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
pmontra 4 days ago [-]
I like TUIs a lot and I use a TUI instead of a GUI as long as there is one available, but please note the main point of the post, the very last sentence
> I barely think about these things as “apps” (I have no intention to distribute them). They’re artifacts of me making my computer do stuff for me, the way I want it to. As a Unix nerd, I’ve always been able to do this, in the language of the command line. Now, it’s just as easy to do that kind of work with graphical interfaces.
And so the author (second sentence of the post)
> I built my first serious Mac application a few months ago, and since then I’ve built more native UI thingies than in my entire career prior to that.
I still build my personal stuff either for the command line (not even TUIs) or in a HTML page but I can see the point of creating a native app. Unfortunately there are some drawbacks: I would have to create the app for GNOME Debian and for Android, while a web app runs on both, and I would have to go all in on vibe coding because my last serious GUI programming has been in the 90s with Motif. The latter point is more or less the point of the author (the LLM does it for you) but it means that programming personal stuff will cost money paid to the LLMs companies. More and more money at each price hike and the multi thousand dollars box to run local models only makes the expense happen immediately instead of diluting over a long period.
thayne 3 days ago [-]
> Nothing is stopping you from designing a dense and economical GUI.
Then why isn't it done more often? I suspect part of the reason is that most gui frameworks are not really designed for making dense economical interfaces.
> you probably don’t need a user interface on prod. You need a command line interface on prod that
I don't need one, but I often want one. Being able to run vim, htop, etc. on servers is quite useful. Also, it isn't just prod servers. It's also nice to run tuis on VMs and containers that don't have access to graphics.
> I’m not really building applications for other people to use. I’m building them for me. TUI affordances are an awfully big hit to take to get Linux users of programs I don’t even want to publish.
Ok. That's fine. But then why are you trying to convince other people not to make TUIs? If I make an app you find useful, wouldn't you prefer me to make a TUI you can run on your Mac to a linux-only GUI?
lee_ars 3 days ago [-]
> Then why isn't it done more often?
Because it tends to require a lot of thought and effort along totally separate engineering pathways than most of the actual functional coding. Good UI design is not easy, and the skills to do it don't directly overlap with good coding skills. It's hard.
> I suspect part of the reason is that most gui frameworks are not really designed for making dense economical interfaces.
Don't blame the tooling for a broad failing of many developers. It's because constructing a genuinely dense and economical interface for most apps requires considerable time and effort, and frankly, most developers are crap at understanding how users other than themselves use applications. Those that aren't crap at it tend to have worked in large teams with dedicated UX people to help drag them away from their preconceptions.
thayne 2 days ago [-]
But TUI's are more likely to have dense, economical, keyboard driven interfaces. Part of that may be the target audience, but I also think TUI Frameworks make it easier to make good keyboard navigation and interactions than most GUI frameworks.
alerighi 4 days ago [-]
To me TUI have a better user experience than graphical applications. And considering the amount of companies that are still using decades old AS/400 systems instead of new ERP system I'm probably not the only one to think it like this.
First, a TUI is usable with only the keyboard. Moving the mouse is a waste of time, and if you are using an application multiple hours a day, it can lead to being more productive.
Second, a TUI has no useless animations, elements, etc. It's not pretty, you have on the screen only the stuff you need to do your job, and you are not distracted by useless elements.
Third, a TUI works beautifully in a client/server world, where you have one central computer and dumb clients that connects to it, and the connection can be a simple serial connection as well as a network connection. It can be rendered even with an ESP32, making it suitable for embedded HMIs and all kind of computing scenarios.
Lastly, the user can choose the font, the colors, the size of the font that are best for him, usually a monospace font that it's surely better to read information multiple hours a day.
To me it's the opposite, GUI interfaces were born to make it intuitive to use a computer, but are not as efficient as TUI in terms of productivity.
codethief 3 days ago [-]
> First, a TUI is usable with only the keyboard.
Is it? Many TUIs these days don't allow me to configure my usual key bindings for moving my cursor within input fields. Meanwhile, GTK offers (used to offer) a way to customize key bindings across all GTK applications. (Unfortunately, they removed that feature in recent versions. Now I understand why people always get so upset about the GNOME devs…)
benj111 4 days ago [-]
The real shame though is that you can make gui apps efficient.
I've used the same systems you describe, except in gui form.
And the thing is, with this kind of application, everyone has a different 20% that they spend 80% of their time using. Guis can be as good as the TUI in the 80%, and very handy in the 20% where you aren't so well versed.
The issue, is that guis seem to have dropped the ball with regards to efficiency.
curtisblaine 4 days ago [-]
Clickbaity title. Boring show off of vibe coded apps that only make sense to the author, disguised as think piece. This post has it all.
jbstack 3 days ago [-]
I found most of the article completely unreadable. I was actually beginning to wonder if the HN post had linked to the wrong article, as it had nothing to do with TUIs until the very end. It was just a long list of "look at this slop code I made" and "look, here's another one!".
rvz 3 days ago [-]
The whole article reads as a post around jealously on the popularity of TUIs and writes a pseudo-intellectual rant about them.
While I don't use most of them, but I can see why TUIs they are popular around devs. But in this post it reads like this:
"I don't like slop TUIs because they are popular, but please look at my vibe coded slop GUIs and I like vibe coding them and you should too"
One of the worst, if not part of my top ten worst blog posts I have ever seen on this orange site and absolutely do not listen to that horrible take that the author just wrote.
3 days ago [-]
swiftcoder 4 days ago [-]
As someone who works on a very GUI-centric OS (i.e. Mac), TUIs just don't integrate very well with the rest of the non-Terminal ecosystem.
They don't support standard GUI shortcuts. They don't support drag-and-drop. I can't double-click a file and have it open in a TUI. They don't integrate with spotlight metadata. They don't ship document icons. They have terrible support for accessibility APIs. And so on...
benj111 4 days ago [-]
It's somewhat an issue with Linux as well.
Ctrl c does 2 completely different things. Terminology is different. Etc.
Problem is. Terminal applications standardised in the 70s. Guis in the 90s. Although that's being undone by web apps, and the influence of touch screens.
picafrost 4 days ago [-]
Are there not disparities between running an application in the terminal and running a native GUI? I can only speak for macOS, but my experience with bespoke native GUI applications of my own or other developers (pre-built distributions in GitHub assets) is that I must first pass through the layers of the macOS security model: doing a right-click dance to launch the application, changing permissions in security settings, etc. I assume the experience is different depending on how you set up Xcode to compile, how it's signed, etc (I have zero experience with how this works). That said, I do not recall being subjected to any of this using terminal applications.
Put differently, a GUI application seems to subject you far more to the whims of Apple or Windows than a TUI and perhaps even a different run context. Maybe the permissions fiddling for this is insignificant. Is there a clear user contract from Apple or Microsoft about this?
Naturally, this is a non-issue in Linux.
pjmlp 3 days ago [-]
Some folks love to live in the golden age of CP/M, MS-DOS, and timesharing green and amber terminals, for whatever reason.
I was alive back then already, and was a relief to finally be able to afford GUI powered computers.
letmehelpyou 2 days ago [-]
[dead]
pjmlp 2 days ago [-]
The golden age was with Amiga, Atari ST and similar systems.
Now everyone ships Electron crap, and then as alternative we are back into the 70's, because they cannot code anything else.
knorker 4 days ago [-]
So wrong.
They're fast, efficient, work across SSH, in a tmux, and survive the almost daily browser upgrades.
And they are easy to run as separate users without VNC or sandbox hell.
Like do you want to think about X/Wayland isolation, or do you just want to get shit done?
Grombobulous 2 days ago [-]
I guess the author isn’t in ops. And that’s okay.
The whole point of a TUI is that it can operate under no-GUI constraints.
I can SSH to any server and use a TUI because SSH can handle that. Running an entire GUI and setting up VNC/RDP would be horrendous by comparison.
Alternatively, a TUI can be a part of an interactive CLI command where it maintains context to your CLI session. For example, I have a tool that helps wrangle AWS accounts and regions where the CLI momentarily drops into a TUI to help pick between regions and accounts if not already specified in environment variables. If I had to type all that out every time it would be very annoying. Hitting some arrow keys or searching with a few letters beats the CLI experience, and a GUI experience is not possible.
dasil003 1 days ago [-]
Here's the part that makes the most sense to me:
> Meanwhile, if I build a TUI, I can be reasonably sure that Linux users are going to get the same experience I have. That’s not nothing. But remember: I’m not really building applications for other people to use. I’m building them for me. TUI affordances are an awfully big hit to take to get Linux users of programs I don’t even want to publish.
If we're just talking about personal or throw-away apps, yeah I'd probably just go native. But for things that I plan to use across platform, via remote shell, and for many years to come, TUIs has a huge advantage. I also think there's something powerful about the constraints of a terminal and the type of solutions it's led to. Constraints breed creativity, and in the case of terminals they also naturally steer towards high-performance, low-latency, and rapid interaction by experts. The fact that these things were born out of the limitations of early computing doesn't automatically make them outdated, to the contrary, it gives them staying power and portability.
In my mind there are crystal clear advantages to GUIs, TUIs, and raw CLI. I've used all of them extensively over the decades, and I've been impressed with the advancements in each over that entire time. I would never presume to tell somebody how to solve their own problems—if you're excited about something just go build it in whatever way makes sense to you.
jmorenoamor 4 days ago [-]
No. I like them.
danpalmer 4 days ago [-]
What do you like about them? I disagree, but so many people seem to like them that I assume I'm missing something. The main one I've heard before is that they work nicely over SSH, but I assume there must be more?
nimih 4 days ago [-]
I personally like making (and using) TUIs because:
- They encourage developing simpler, information-dense, and keyboard-driven interfaces, which I tend to prefer in general.
- I find them more fun to write, and less aggravating to maintain and debug, than interfaces built with GUI toolkits.
- Most software I write for personal use is going to be run in both a Linux and Mac OS environment (and a lot of the time on a headless server to boot), and a TUI often has less fuss than other options (at least, IME).
- I think monospaced text in a terminal just looks cool.
annapanna 4 days ago [-]
But you can't really do information dense when you are limited to a fixed grid of monospaced character glyphs.
Variable width fonts are much more information dense for example.
nimih 3 days ago [-]
By "information dense," I meant in contrast to what is typical in modern GUIs: generous borders and margins between interface elements, large buttons, etc. My experience both using and writing TUIs is that, because of the extreme limitations of your tools w/r/t styling and layout, more of the screen real estate tends to be devoted to displaying data, and on whole I prefer that.
YMMV, of course, I'm just sharing my own experience and perspective.
croon 4 days ago [-]
I prefer TUIs personally, but I can't see myself use maps, or visual image editing in a TUI for example, but is vi infinitely faster than vscode for manipulating a codebase? Absolutely.
Anything that lends itself to keyboard input, piping, text manipulation and a bunch of other things are so much faster if you're equally proficient in both input modes.
beej71 4 days ago [-]
I think the "fun as hell to write and use" angle is underrepresented in the comments—thanks for bringing it up.
It is, of course, completely subjective, but I know there are a fair number of people out there who agree with that statement.
barnabee 4 days ago [-]
IMHO the rise of TUIs is heavily correlated with the near-abandonment of professional quality graphical interfaces.
If there was a powerful, information dense, configurable docking/tiling, multi-application-composing GUI framework (all things a good terminal can do) then yes, build everything in that. I’d love to see it.
Until then, TUIs are vastly better than another Electron app or Mac app using UI frameworks that are trying their hardest to look and act like basic phone apps.
funlang 3 days ago [-]
Yeah, I feel the same. Most modern GUIs waste so much space and hide actions behind hamburger menus – TUIs just get out of my way and let me work fast. I’ll take a well‑made TUI over a sluggish Electron app any day.
anon7000 3 days ago [-]
Nailed it. As the blog post says, GUI’s aren’t normally written for nerds. They exist, but it’s not normal.
So even professional tools all follow industry design and product trends which are too simplistic, don’t give you the info you need, and are optimized for abstract brand design or chasing metrics for the company, and not optimized for “how do I let my user accomplish their task as fast as possible”
mrheosuper 4 days ago [-]
Lightweight and can run over ssh are 2 main reasons i like them.
takluyver 4 days ago [-]
In addition to what other people have said, the terminal interface is cross-platform and very stable, so TUIs need little or no maintenance to keep working.
TurboHaskal 4 days ago [-]
I don't think TUIs are inherently better but some are simply too good versus the alternative. magit and k9s for example.
anon7000 3 days ago [-]
Also CLI args to TUI are very useful. Like the k9s command flag to take you to any view. It feels more immediate than launching a separate app from the terminal
duskdozer 4 days ago [-]
(other user) in my typical experience:
- keyboard can be used for pretty much everything
- less visually busy (no/less animations, background images/color variations. often close to plain text on plain background)
- more information dense (fewer things hidden behind hamburger menus, modals, drawers, etc)
- more/more easily customizable and documented
- more often can provide data directly into the terminal that I'm working in, so don't need to copy/paste through windows etc
these aren't necessarily impossible for GUI or universally true for TUI, but maybe I would guess just more an artifact of there being types of people who prefer working in the terminal who are then more likely to make TUIs, and I share their preferences more.
Linux-Fan 3 days ago [-]
I use the terminal for most things which are not web browsing hence for me it makes sense to prefer TUIs for "lightweight" GUI needs.
I love how I have to configure font size and family only once in the terminal emulator and not for each program/GUI toolkit again.
Of course, there is no way to replace graphical-heavy programs (GIMP, QGIS etc.) with TUIs.
I also like them so I can mention some things that spring to mind:
- Some are very good tools that have no clear GUI superiors. Vim, Emacs, Mc for example. GUI wrappers over these don't make them better.
- Efficient, meaning fast and limited in scope so you can learn the whole thing.
- The muscle memory you develop is transferable to any new platform or OS you use.
- Often free and OSS so they can't be taken away, making the muscle memory a long-term investment.
- If you work in the terminal for any other reason there's less context switch.
bcrl 3 days ago [-]
Muscle memory and awful connectivity in remote places (well, not even that remote for me) is what so many GUI apps undervalue, and I don't think the author of the article has ever thought of or encountered this. I loved TUIs back in the '80s and '90s when convention was so consistent across applications that muscle memory transferred seamlessly. Plus one could use a mouse to select menu options or the keyboard (like the many Microsoft programming environments like QuickBASIC, QuickC, Microsoft C as well as competitor products like Turbo Pascal and many others).
The low bandwidth / high latency lossy link problem is still a major issue. Cell phone service is sufficiently shitty in the area I live in that I have to use mosh to get a usable remote connection many times a year. Mosh is also quite useful while travelling! Got a crappy connection on a train or airplane? No problem. I have so much muscle memory with the mutt email client that nothing else has ever come close. Where's the equivalent of mutt's limit command in Thunderbird?
Try getting a usable VNC session when your cell phone hot spot is hitting 2-30 second ping times (yes -- thirty seconds) with only a handful of packets getting through.
Version 2 of the Amiga's operating system did a great thing in version 2 of AmigaOS which explicitly spelled out what conventions to apply (see Amiga User Interface Style Guide at https://archive.org/details/amiga-user-interface-style-guide). Modern GUIs that have weird meaningless buttons are infuriating. Even moreso when they lack obvious keyboard shortcuts.
jmorenoamor 4 days ago [-]
A good UI can be text, graphic, voice, etc.
I enjoy the usability and self perceived speed of not having to leave the console or reach the mouse to move a pointer when a cople of key presees is enough.
It's a matter of choice, I know, but I also think there is a genuine case for text over graphics. I see it everyday on businesses that keep old cobol tpvs at the cash, the speed at which the clercks check inventories or perform other crm activities is unmatched to mouse or touch interfaces
skeledrew 4 days ago [-]
It's easier to automate TUIs, since it's just text.
benj111 4 days ago [-]
Nit.
Surely it would be keyboard navigation? Your macro can consist of the key presses you would actually use, rather than trying to describe mouse movement.
If you want to automate from the perspective of what's on screen, tuis have no metadata. A button in a gui does have metadata associated with it, so you could automate 'click button x' where as in a TUI you'd be limited to clicking 'position x,y'
skeledrew 4 days ago [-]
You don't really need metadata to automate in a terminal. Literally everything is there in the clear and ANSI is used for control. It's all characters; no need to think about pixels (I made something that automates TUIs[0] BTW.
For GUIs you have to handle the particular metadata of a given framework, if it exposes metadata at all for the controls. Otherwise you're dealing with raw pixels which is an instant nightmare, though not so much now there are visual LLMs, but you're still paying for the tokens and/or extra processing.
Ah ok. I was thinking from the perspective of automating the input, for a human to view, rather than automatically getting data out.
skeledrew 4 days ago [-]
Automating input is just sending character codes. It's all wonderfully simple and uniform.
catlover76 3 days ago [-]
[dead]
smcleod 4 days ago [-]
I absolutely love TUIs, they can live in a pane in my terminal, run via SSH on remote machines, use hardly any resources and are very flexible.
novoreorx 3 days ago [-]
Bit of an overstatement, but I agree with part of it:
- A lot of TUIs that run on your own machine and have a mature GUI alternative are indeed not necessary. I once tried to replace Spotify with ncspot, which was exactly falling into the "TUI is more advanced" trap.
- The real target of this article is people who treat TUI as a kind of identity, not people who have to work in a terminal because of their job and therefore have plenty of good reasons to use TUIs.
But the title and the general tone are still too clickbaity, which is kind of annoying. In reality, apart from a small portion of TUIs that were created just to follow the trend and clearly have better GUI alternatives, most TUIs are really just side tools that grow out of one premise that we have to work in the terminal.
And even those flashy TUI tools still make life easier for people who work in a terminal. If you prefer GUIs, fine, you don't have to use them, but that doesn't mean they have no users or no value.
kccqzy 3 days ago [-]
> The real target of this article is people who treat TUI as a kind of identity
That’s exactly what I thought too when I read the article. When the author mentioned the essay In the Beginning Was the Command Line I instantly knew it. I thought to myself the audience of the article must be the people who had read the essay and allowed it to influence their taste, as well as the people who might not have read the essay but conversed with people who did.
api 2 days ago [-]
Accessibility is a giant problem with almost every open source GUI library too.
It seems like an absolute slam dunk for AI. Create an integrated AI screen reader app that observes the screen and talks to you. It wouldn't even need to be a huge model. It could be a small local model that can just read and interpret UI elements and feed the results as tool use calls into an accessibility layer. It'd probably be a custom trained accessibility model, could probably be based on an existing small computer use model fine tuned for the purpose.
This seems like the "accessibility solution to end all accessibility solutions" that totally takes the burden out of the code and puts it in one place that can be uniformly improved.
This is the way. It just wasn't possible 5 years ago.
jesse_dot_id 4 days ago [-]
I'm a fan of a TUI, I think because they are usually pretty intuitive out of necessity. I can usually feel the developer's skill level in the user experience.
hiAndrewQuinn 4 days ago [-]
I like TUIs, and I chose to build e.g. https://taskusanakirja.com/ as a TUI for a couple of reasons, some of which are in this article and some not. Cross platform compatibility was a big one since at the time I started building it I didn't actually have a Windows or Mac machine handy to test this out.
One thing I think which is overlooked is the raw feeling of speed a good TUI can give you. The lowest grade consumer laptop could probably download my little dictionary program and still get true search-on-keystroke performance, because there is virtually nothing slowing down that path, no animations, no nothing. Now most of that comes down to the data structures involved and making sure nothing ever has to go over a network, but I still appreciate the sheer simplicity of the approach.
It's also nice to know that I can probably recompile this same exact code 50 years from now and still get it to run exactly as intended, since GUI frameworks have waxed and wanted in popularity, but terminals truly don't seem to be going anywhere.
lelanthran 4 days ago [-]
> One thing I think which is overlooked is the raw feeling of speed a good TUI can give you. The lowest grade consumer laptop could probably download my little dictionary program and still get true search-on-keystroke performance, because there is virtually nothing slowing down that path, no animations, no nothing. Now most of that comes down to the data structures involved and making sure nothing ever has to go over a network, but I still appreciate the sheer simplicity of the approach.
Recently, I posted a GUI mp3 playing program written purely in Tcl/Tk using shell scripts for some things. On my 2011 desktop, filtering for a specific mp3 across all the mp3s stored on my computer (about 80GB of mp3s) takes single-digit milliseconds. I can only imagine what a modern desktop, with an SSD, will do!
GUI apps don't have to be laggy. My Qt and Lazarus apps aren't laggy at all, and are far more snappy and responsive than the clear majority of TUIs I use (like CC).
jbellis 3 days ago [-]
Unfortunately we seem to live in an era where your mainstream choices for a cross platform app are "Electron taking 1GB when idle" and TUI.
tomaskafka 3 days ago [-]
No, that is 2 years ago era.
Now it’s “native apps for 5 platforms done almost for free” era for anyone who cares.
See Meta’s new AI desktop app (no, I won’t install anything from Zuck on my computer, but I appreciate what they did).
xgulfie 3 days ago [-]
> Now it’s “native apps for 5 platforms done almost for free” era for anyone who cares.
Can you elaborate?
divbzero 4 days ago [-]
It’s a matter of preference: Everything OP says about GUI development getting easier is also true about TUI development getting easier.
cube2222 4 days ago [-]
Yeah, I think I agree with this. I think making GUIs and reverse engineering proprietary APIs are two things that frontier models make really pleasant - e.g. I made a menu-bar app (very similar to your temperatures dropdown, similar graph, SwiftUI) which connects via bluetooth to my Inkbird CO2 sensor, graphs the CO2 level over time, and looks fabulous.
The skills are useful, thanks for linking them! They'll be useful for my future projects like this. FWIW I've had good luck with using Claude Design first to do mocks.
At the same time, I think there's still the "is this worth doing a hyper-customized version of this software, if I'm also then responsible for fixing the bugs?". But I think increasingly as we improve our agentic workflows and make them more self-contained loops driving the result to completion, this becomes kind of a non-issue.
In general, I do think LLMs are bringing about a new age of hyper-customization, which I welcome.
ammar_az 4 days ago [-]
I like to have my freedom in choosing what software I want to make/use, without anyone dictating what is better for me.
You like GUIs and want to build/use ones that works in MacOS, that's perfect go ahead and build as much GUIs as you want.
However, this wouldn't work for me as I know how bad developing native cross-platform GUI applications is.
lukasbm 4 days ago [-]
TUIs are just an accessibility nightmare without any of the advantages of a CLI like scriptability. Truly, Truly horrible
Gormo 2 days ago [-]
That seems at odds with many of the people in this discussion communicating that they find TUIs more accessible.
cadamsdotcom 1 days ago [-]
TUIs are better for typing centric keyboard workflows; GUIs are better for keyboard shortcut centric. Your desire UX will guide you.
People don't expect to be primarily typing into a GUI; they expect to occasionally click something interesting; have things pop into view as they happen, etc.
A TUI's advantage comes partly from imposing a constraint: how can we make close to all the user does in this thing and make it doable by typing at this cursor?
As always it's horses for courses.
nickpsecurity 2 days ago [-]
I enjoyed the article. He has good points. I'll emphasize one and add a other.
1. CPU/memory performance on cheap or throwaway systems has a niche benefit. Mostly poor people. I'm still usually on an ancient Thinkpad with a 2nd gen i7. It runs native apps really fast to this day. Almost all GUI cuz I agree with the OP but my apps are TUI by default to keep them lean and fast.
2. Security. While I don't aim for it these days, it was much easier to make textual apps securely than GUI apps. Secure OS's from the 90's already secured console apps. TX, Nitpicker, and EROS made progress on GUI's but there's high complexity still. I'll note the OP's idea of GUI front ends is basically what we did to isolate the GUI part in a dedicated partition with messages it sends checked by the secure component.
Other than those observations, I'm with OP where I'm tired of TUI's if GUI's are that easy now. I considered trying it with some lightweight, cross-platform frameworks. Anybody tried some with cheap AI's?
closetheloopdev 4 days ago [-]
If you want to live only in the terminal, you can also use one of the text-based browsers [1] instead of Chrome, Firefox, etc. browsh [2] can also play YouTube videos if you'd like.
You can also just use the system console with tmux or GNU screen if you absolutely don't want any graphics at all.
The TUI programs usually do not consume a lot of resources. They are also very fast and optimized for keyboard-only navigation.
The site layout is great for reading, so props to the author.
I understand the sentiment that TUIs is not as accessible, sucks to use. I still do not like the fact that we should "stop making TUIs" altogether.
Let me give you an example from my carpenter friend in Cananda.
He has a saw (TUI) and electric one (GUI).
He uses the saw in diff ways than his electric one. He sometimes extend the saw by attaching it to end of a long stick to cut tree branches he cannot reach. He can do it with the eletric saw but requires much more effort.
But if he needs to cut down the tree, he uses the electric one, and sometimes finish off (trim) with the regular saw (so the tree falls in certain direction).
The gist is, TUIs can be used to do things quick and dirty, and easy/cheap to make/buy. GUI even with AIs, still not as cheap as TUIs to build.
TUIs has a different usage in our field, where it's used more for automation/piping. If you have GUI, it's hard to pull it off unless you build the functionality (which coulda been a command in TUI), and expose it via GUI. the Authros is focused more on consumer side than builder side. With AIs we will all be builders using AIs.
Lastly, shooting down people building TUIs is saying, no more innovations, by building upon other's TUI inspirations.
kunley 4 days ago [-]
What is the complaint in the article really about?
People write code using the platform X because they like it. It doesn't make sense to try to stop this
FerretFred 1 days ago [-]
TUIs are great and I shall continue to write and use them while I can still see a screen! My use case is to mainly use Termux on my ruggedised Android tablet, simply because I can't install a native Linux on it. I like the speed and efficiency of a TUI as well as the fact that I can maintain it with vi or nano. I've installed XFCE4 on it for fun but the extra, necessary library baggage isn't really worth it, TBH. It also means I can use the same stuff on my Onion Omega 2 SBC with minimal tweaking.
the__alchemist 3 days ago [-]
Three broad notes:
- I'm team GUI! The author outline elegantly why. Sometimes I put command-line-like things in the GUI; I generally view it as a superset of CLI, with vastly richer capabilities. This is kind of interesting in the bioinformatics/structural bio space, which I feel is inherently visual, and benefits from 2d layouts. Most of the tools are CLI and based in I/O of stdout and text-based files. I am taking a different direction!
> Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing industry on their shoulders. The Eloi use GUIs like Microsoft Word. Because this is high-test fan-service, “In The Beginning Was The Command Line” has become one of our field’s sacred texts, despite very little of it holding up 25 years later.
We should not take Sci-Fi and creative plot devices as predictions for the future. They can be inspirations and motivations for your own creativity, if tempered by realistic expectations and discipline. Neal Stephenson is especially prescient (Certain concepts from Fall; or Dodge in Hell and Anathem are hitting home strongly right now!). He spins vibrant, speculative yarns, mixing concepts, and estimating trajectories. The story referenced he is one that's in particular easy to see what parts did and didn't pan out. (And what Neal's more recent reflections on it say)
I think there is a bit of cultural identity (Which we are genetically inclined to insert in all sorts of places!) going on. There is a certain cyberpunk fun in SSHing a terminal, pipeling stdout/in together, and Viming. I suspect there is a high overlap between people for whom Linux is part of their identity, TUI use is as well. I.e, it's not about a practical weighing of merits; standard identity/tribal-based choices.
FOr use of TUI as a general file browser/command-executor... I've made my own. It's a GUI, and has built-in terminal for executing commands, with a visual file browser. And most importantly: Shortcuts to execute commonly-used workflows, history, bookmarks etc. All of which I feel like are glaring things missing from standard terminals. (PS, Bash etc). And having a terminal as one part of a multi-window program feels like a good use of my screen space!
rixrax 3 days ago [-]
"Q: Son, what is window manager needed for?
A: Running multiple terminals on one display."
laktak 3 days ago [-]
tmux
alimbada 5 hours ago [-]
My servers can’t and shouldn’t run GUIs so you can take your “hot take” and stuff it... somewhere else. Choices are great to have. Advocating for fewer choices deserves the derision it’s been met with in the comments here.
mikedd 3 days ago [-]
Stop telling people what to do :/
Let people enjoy things.
gemisis 4 days ago [-]
Hot take: Too many people are building GUIs for what should just be a TUI, and vice versa
My stances:
- Dev tools need a CLI at minimum, TUI for complexity
- User facing needs a GUI, CLI for power users
If you're building a TUI for a user facing thing, then yeah, you're doing it wrong, but if your target audience is devs then yes, PLEASE do a TUI, and make it nice.
ejboy 2 days ago [-]
One big benefit of TUIs is that they lower the bar for customer adoption. Before Claude Code, it was unthinkable to come up with a mass-market TUI because most users would not use it simply because it's a terminal. Now, it can even be an advantage. Even inexperienced users are no longer afraid of the terminal.
stianhoiland 3 days ago [-]
You can't tell someone who doesn't like the command line why it's so awesome.
EDIT
> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.
Oh, right. I can see that, but I go the other way: When I have a CLI, don't give me GUIs; give me files. Actually, just give me files and daemons. I'll do the rest, thank you!
skapadia 2 days ago [-]
How about build whatever interface makes sense for the user? Doesn't matter if it's a TUI, GUI, speech interface, or some physically actuated / haptic feedback based system. Do what makes intuitive sense to the user and provides enough expressive power to get their job done without overwhelming them.
lawnchair 3 days ago [-]
> Our field has a weird relationship with terminal and command line interfaces. The time has come to re-evaluate it.
I like chocolate I like vanilla
burnoutdv 4 days ago [-]
I am team TUI for the matter.
Its also a bit funny how the author show cases a bunch of apps that only exist on a very specific setup, IOS Mac devices while TUI can exist everywhere a terminal can reach.
The right tool for the right job, noone would srsly use a TUI photoeditor but for many things the simplicity and constraints that a terminal introduces condenses design.
I got this article about UI density open since weeks and meant to read it https://mattstromawn.com/writing/ui-density/
But from what I could interfere so far..more UI frameworks, more white space, more wasted space.
Also..TUIs usually allow me a wide variety of colorschemes out of the box which is nice
21 hours ago [-]
greatgib 3 days ago [-]
> Next: TUIs work over SSH connections. If you need a user interface on prod, it’s going to be a TUI.
With X based apps, you can run GUI apps through SSH. That was all the rage for light remote access to resource hungry desktop app a few decades ago...
But that being said, in my opinion, a few limited TUI apps are useful, but most of them nowadays are young "cool kids" that wants to be cool by using "terminal apps" without really having really embraced the spirit of the terminal and commands.
For them, using GUI apps would look like a basic computer user and not an expert nerd.
The magic of the terminal, is not that you run things in almost black and white with low graphics, but that you were supposed to use "simple" commands that you can scripts and pipe one through each others at will.
3 days ago [-]
Retr0id 3 days ago [-]
Stop making TUIs, stop making GUIs, and make more CLIs. Claude can read the help text and efficiently drive it directly, without needing a vision model in the loop. Then I can go outside and do more something more interesting while Claude plays computers without me.
porridgeraisin 3 days ago [-]
Claude (and many models, deepseek, etc) can operate a TUI just fine by reading and sending control codes to a PTY.
xlii 3 days ago [-]
More TUIs, and with eye candies too! :)
Since I wrote my own terminal multiplexer that puts terminals on infinite zoomable canvas [0] and I just can't get enough of putting weird stuff like asciiquarium, cmatrix or tty-clock all around (tried peaclock but it's slightly too fiddly for my taste). There are fun projects just to run in TUIs like astroterm or weathr, but I'd say that the space is still open to terminal toys.
The only problem I have with TUIs is that they're boring after a while but something that can be solved with often theme switching.
The CLI/TUI split in the article is right, but to me the more interesting boundary now is human-facing vs agent-facing interfaces. For most things TUIs lose on both sides.
We run an internal agentic development harness we experimentally built for working on large-ish projects. first version started as a TUI, but it quickly became unusable for the large scale projects it was meant to work on (essentially PRD to PR, with planning loops, task decomposition loops and dependency aware execution / review loops). The TUI was too state-bound for another agent to drive reliably, and too cramped for a human to review at scale. We ended up replacing the TUI with a headless cli, and every interface we've built for the harness has become either a text artifact (mostly for agents to work) or a web view (for humans to drive and review).
voodooEntity 3 days ago [-]
Tbh in a time where more and more applications are shipped as vibecoded electron based bloated bug-collections that are slow and take stupid amounts of resources i'd rather have even more TUI's than less.....
willjp 3 days ago [-]
TUIs work where I do.
I don't want to juggle another window unless I need to. Tmux gives me better ways of organizing my work than most display managers. Most of the useful things I do end up calling other shell commands, and it's nice having terminal right there. Ctrl-t / fg are also uniquely powerful.
UIs are also useful for information that is best represented in a UI. keep using those too.
You can bend each to be more similar to the other, and that's good too! Sometimes there is a good use case for that.
JKCalhoun 4 days ago [-]
"I’m glipping balls like everybody else."
Well, that's a new one, ha ha (guessing "tripping balls" on GLP-1).
(And here I am too, about to be glipping balls… like everybody else, I suppose.)
stephc_int13 2 days ago [-]
TUI are often inferior to GUI from a user perspective, but not necessarily by much.
On the other hand, they are easier to build in a cross platform manner.
Linux is probably the most difficult platform to build GUI for, because of all the fragmentation, X11, Wayland, all the different flavors of GUI toolkits, driver issues, window managers issues, font issues etc.
TUI are a bit like web apps in that regard, using the terminal instead of a browser to abstract the platform.
jimmydoe 2 days ago [-]
> a user perspective
a lot of boomer and millennial dev users love TUI bc that's what they grew up with. part of A\'s early success is hit that sweet spot and triggered a culture shift late last year.
as those age group phasing out, web ui will be dominant
Asooka 3 days ago [-]
If writing a GUI was as easy and stable as writing a TUI, yeah we should write more GUIs. I can run practically any ancient TUI program on a terminal emulator, but running a GUI program that uses an older version of GTK means going through dependency hell to compile and install all the old library versions. If they even compile with the new GCC... I really wish we had a standard way to spawn a webview (or similar) and connect stdin/out to it.
bborud 4 days ago [-]
I think it depends on how you work and what the application does. When I'm in a flow state I need things that are fast. GUIs, even on my relatively fast mac are not terribly fast. They take more time to start. They require more screen real-estate, and more management of same.
For something to become a GUI app (or a web-based UI) the GUI needs to offer something more valuable than a TUI can offer in terms of interaction.
I have one TUI app that wrote a while back to keep track of what I work on. It started off as a "wizard"-style UI. You choose project, then subproject, day, hours, activity and then hours and comment in a sequence of steps.
Arrow keys -> enter -> arrow keys -> enter .... -> comment -> enter
It takes about 2-3 seconds for me to do. And this is a time-sensitive task: if it isn't fast the user will not do it as often. There is a web interface to do the same thing, but the backend is slow. My TUI utility speeds that up by caching (between sessions) the things that the web UI has to look up (slowly) every time.
Then I wrote a more involved UI for it that "looks more like an application". Result? Now we were up to 15-20 seconds of interacting. Oh year it could do more and it certainly looked better, but it was less efficient so I noticed that I would postpone using it to record what I was doing. Because it now had friction. Lots of it. So a couple of weeks later I just did a hard reset and went back to the wizard style, minimalist version.
I would make a web UI, but that would burn 2-3 seconds just to navigate the browser there, juggle tabs (which I have too many of already), find the right browser to open the tab in etc. Once there do I keep it for "faster access" or close the tab? Keeping it is almost always the wrong thing.
There's a reason I have perhaps 15 different tools in my garage that can attach to a given fastener size. And there's a reason for that. Not all 19mm bolts are treated the same way. Some are low torque and live in tiny spaces. Some require precise fastening torque. Some need a lot of force to come loose - some will only come loose with force and I'm okay with destroying them. This is why I have so many tools that all do essentially the same job: apply rotational force to a piece of metal that has a standardized interface.
Similar tasks are not always best solved with the same tool because the context and the details do matter. Same goes for UIs. There are some things TUIs are very good at. Not least portability and remote usability.
globular-toast 3 days ago [-]
I agree with the author, as long as you keep the good bits of TUIs, i.e. keyboard driven and fast. There is absolutely no reason why a GUI shouldn't be strictly better than a TUI.
I'll just copy a comment I made about this in another thread:
TUIs are just GUIs that use a grid of characters instead of pixels. They are strictly worse than true GUIs, by definition. The only thing I liked TUIs for is running over SSH, but can any of these newer ones really run over SSH with any kind of decent performance anyway?
I think people are confused and think they like TUIs because they like them being keyboard driven etc. But this could all be done with a GUI.
The other factor is probably just fashion. Similar to how some kids are now listening to music on cassette tapes, which are objectively worse than other media in almost all respects. The less cynical take is it's like vinyl: it does come with compromises but gives us back some of the things we lost over the years.
The actual interesting text-based interface is the CLI. I've seen a few examples of TUIs that really should be a CLI and would be much more useful as such.
4 days ago [-]
pkulak 3 days ago [-]
And the very first app example is a Mac-only markdown viewer. If only it was a TUI; then I could try it out and partake in this conversation!
jameshart 3 days ago [-]
Because the author wanted the ability to open and browse markdown files when you double click them on a Mac. How would a TUI better serve that purpose?
Just like MCP is for Desktop users and useless otherwise -- GUIs are a solution to a created problem.. of users not being able to read and write very well because they don't practice.
Terminal, coding, and even prompt writing skills are language skills.
If you cannot use a terminal properly you are basically an appliance user. Like a toaster operator.
TUIs are not for everyone by design.
elvin_d 2 days ago [-]
Contentious topic but I have hard time comprehending line height scroll instead of smooth Web like experience and everything rendered in the same font size. I guess it’s a habit for people who started early and never got to use web applications enough to develop distaste to TUI scrolling patterns.
zzzbra 2 days ago [-]
Found this article to be a bit of a slog, burying the lede until after you’ve sifted through a rambling list of irrelevant vibe coded apps by OP. The actual argument came across in places but I am unpersuaded. Unsure if that’s due to the article structure or the argument’s own merits.
sochowski 4 days ago [-]
> But there’s one of the problems with TUIs: even with a good framework, like Ratatui, Textual, or Bubbletea, you’re fighting the terminal to come asymptotically close to what every native framework does well out of the box. Scrolling and scroll targets are an obvious example.
maybe the answer is... you just don't need features like scrolling? this guy is trying to fit a square peg into a circle hole
rvz 3 days ago [-]
The entire article is close to rage bait and should be dismissed as such.
vrypan 2 days ago [-]
> We build terminal interfaces because we have to, not because we should.
Who said we're building them because we have to? I like TUIs, and often prefer them over GUIs, depending on the case.
sgt 4 days ago [-]
Question about Markdown, I'm intrigued by this. I recently bought FS Notes but it has some bizarre bugs on startup. I might consider some other tool, perhaps also something with better MD support. Is this library you mentioned truly fast? https://github.com/gonzalezreal/swift-markdown-ui
It's funny I'm currently creating a TUI. A mutt like mail client. I didn't have any second though to consider GUI for the project because it's so ridiculous.
It's inherently cross-platform (msys under windows). It allows to copy any part of UI. It doesn't require dependencies other than curses.
DonHopkins 3 days ago [-]
In the age of graphical user interfaces, direct manipulation, info visualization, WebGPU in the browser, and frontier AI, it seems ridiculous to have a VT100 escape code interpreter between you and your LLM.
Like Brooke Shields, I'd rather nothing comes between me and my LLMs.
bitwize 3 days ago [-]
Going into this article my attitude was "don't tell me what to do!" but I kind of see his point.
Back in the late 1980s, there was no question—the Mac changed everything, and everyone agreed that graphical was the superior interface. But we in the Unix world were slow to convert fully, because of a couple of problems:
* designing GUIs is hard, especially for programmers;
* writing GUI code is hard (and often tedious).
So good GUI apps really came from teams of elite designers and developers. The best ones all worked for Apple. There was an acceptable second tier that all came from major companies. If you wanted to write a custom one-off tool for yourself, however, you'd be in for some pain and the result would be jank.
But LLMs solve both problems. Point Claude at a description and some mockups of an app, and it will give you that app, or at least a slick-looking prototype that is suitable for your use if not the wider market's. So we no longer have an excuse. ALL our apps should be graphical, because creating graphical apps is now easy.
Gormo 2 days ago [-]
> Back in the late 1980s, there was no question—the Mac changed everything, and everyone agreed that graphical was the superior interface.
No, they didn't. The Mac's GUI benefitted in certain specific applications, like DTP, early on, but the Mac was an also-ran for most serious productive work for a very long time, and even when GUIs became standard in the PC ecosystem, it wasn't until the late '90s that productivity apps decisively moved from the DOS-based TUI world to Windows GUI applications.
> So good GUI apps really came from teams of elite designers and developers. The best ones all worked for Apple.
The folks who actually managed to build interface paradigms that successfully reconciled complex business functionality with sufficiently easy-to-master GUIs worked mainly for IBM and Microsoft. The CUA paradigm was the winner here.
People seem to forget that Apple had next to zero penetration into the business computing market, and nearly went bankrupt, back in the '90s.
Razengan 3 days ago [-]
Have there been any attempts at graphical TUIs?
As in, using graphics, vectors, but with a fully text-based UI?
unexpectedtrap 3 days ago [-]
Plan 9 is essentially exactly that, which clearly was inspired by the Oberon’s GUI. By the way, does then Emacs count as such? Or maybe you should take a look at Genera, however, I’ve never really tried it.
Also the original Metro design as in WP 7/8/8.1 or Windows 8/8.1 relied heavily on the pure text, and the only place populated with a lot of icons was that iconic tiled start screen, although this is probably not what you mean.
skeledrew 4 days ago [-]
Making TUIs isn't the issue. Making them with JS/TS, and in general an ecosystem designed for the web, is the problem. I've used some really good TUI apps in the past, but all these new ones mostly based on web tech are just... sloppily bad. Probably because the dev would rather be in the web browser where it's naturally colorful and scripts can run wild, but mostly-static terminal is where things are currently at. And they're using LLMs, which don't have sufficient data on web-tech-in-terminal since it wasn't really a thing until now, which also ensures they will likely never gain enough data on decent patterns since almost nobody will be engineering said patterns, creating a permanently slop-ridden cycle as future models only have slop projects to learn from.
yayitswei 2 days ago [-]
One point for TUIs I haven't seen mentioned: they're faster for coding agents to iterate on. No need for screenshots or computer use. Agents have made GUIs cheap, but have made TUIs even cheaper, both to build and verify.
inevletter 2 days ago [-]
Honestly I would stop making TUIs if we had a better alternative to Electron/Tauri for multi-platform apps that run natively. I will keep building TUIs because they are the easiest way to reach support all OSes.
rowbin 2 days ago [-]
While GUIs have some legitimate use cases, I prefer TUIs if I can get away with it. Its just text, ssh friendly, constraint in a beautiful way that still allows endless possibilities.
cavem0nkey 2 days ago [-]
You can shit on TUIs but macOS isn’t the panacea of GUIs. This really compromises the argument. In fact I’d argue it’s one of the worst platforms for GUIs.
Sure it looks pretty but it’s impossible to drive from the keyboard without mutant hands and savant level of memory for arcade combos. That means the entire OS relies on being able to drive the UI from a positioning device and thus you have to have the coordination to piss on an ant off a moving train. Which is terrible when the input devices are a touchpad, which varies so utterly frustratingly depending on whether it’s in the laptop or over Bluetooth. That and a mouse which is designed by a complete psychopath. That leaves you with third party options which require apps to not suck and they still suck. Scrolling on Logitech options anyone? Even LinearMouse can’t fix that shit.
Compare windows which works absolutely fine from any keyboard or any mouse and is discoverable and consistent. Also no mutant hands required.
TUIs are closer to windows than macOS. And that’s a good thing.
I did the last ten years on a mac and decided I was just hurting myself. Give me windows or a TUI. I notice Linux desktop environments tend to copy windows with respect to keyboard and discoverability too.
heymaikol 2 days ago [-]
This is probably why TUIs feel so comfortable on Linux. Keyboard-first interaction already matches how a lot of Linux users work.
4 days ago [-]
kelvinjps10 3 days ago [-]
built my first serious Mac application
This the first thing if they stop making tuis we linhx users will get slow electron apps
I prefer a tui over an eletron app or even worse not getting any apps at all
lo0dot0 3 days ago [-]
> shorthand inputs that make common operations (like “take the gradient of this expression”) quick to type
There's a shorthand that derives from the Phoenician string instrument : nabla . Latex has it as \nabla
m0llusk 3 days ago [-]
Text is an extremely information dense medium. It makes sense for user interfaces to be centered around text. This keeps the focus on the data and its transformation.
swader999 3 days ago [-]
It's interesting going to order auto parts or construction materials. All old tui like console programs if you look at what they use. They are good and quick at them too.
x0xMaximus 4 days ago [-]
aerc is the best program I've ever used. tmux from anywhere. May TUIs never die.
knorker 4 days ago [-]
If there's anything that's anachronistic, it's native apps.
You want it graphical: Make a webapp.
You don't: Make a TUI.
What exactly is the use case for native apps? Even lots of legacy code can build to WASM now.
(yes, I'm exaggerating a bit, but not much)
err4nt 4 days ago [-]
As a web developer who has just begun building native apps: running outside of the various sandboxes browser based apps are quarantined in. Deeper file system access, better access to hardware and sensors, notifications where helpful, deeper integration into the operating system (open with, file previews, widgets to launch the app, etc) and performance. Some things the web does well, some things it does less well than native. With a native wrapper around a web app you can leverage the best of both!
vivzkestrel 3 days ago [-]
stop making your blog take 20% width on my 4k monitor
scotty79 3 days ago [-]
TUIs are great as a layer above bunch of commands with too many commandline parameters and flags. For everything else .. no, thank you.
abcdefg12 1 days ago [-]
As decades of cli and TUI dev and user - TUI forever
yeodev 3 days ago [-]
I think OP is missing the point of TUIs: They kinda work everywhere. While I need to fuck around with a operation systems native UI libraries like WinUI, SwiftUI, GTK, etc. I can just build an app in the terminal and be fine with it running on almost all platforms.
I'd take TUI apps over electron apps everytime as long as the UX is good.
lo0dot0 3 days ago [-]
No. TUIs do not work everywhere. They can break because of terminfo which I really don't want to deal with. I hate wasting time on such configuration issues.
migueldeicaza 3 days ago [-]
Possible, but rare in practice.
Nowadays, you are more likely going to struggle with plugging your laptop into a 320Volt outlet than have a terminfo problem.
loeg 2 days ago [-]
The article is interesting even if you disagree with the headline conclusion -- don't skip it on that basis.
bentt 3 days ago [-]
TUIs are by definition keyboard first.
TUIs are a creative constraint.
TUIs are an invitation for programmers.
TUIs are doing "less" to render.
TUIs don't need to be "responsive".
Hello World is TUI.
avmich 3 days ago [-]
TUIs are good for users, because they don't require using mouse as much - I didn't see this argument covered.
refsab 3 days ago [-]
I think I'll keep making TUIs but thanks.
Easier to test too. Try testing your beautiful claude design React app end to end
Kon5ole 3 days ago [-]
The aggressive headline is a hook which is what bloggers have to do I guess, but it doesn't need to be polarizing. The argument boils down to "If you made a TUI only because making a native app is hard, then LLM's fix that for you now".
Making GUI apps has been way too hard on all platforms since forever. Frankly I think it's gotten worse for 20 years. People started fleeing to web wrappers like Electron to escape the horrors of native UI development.
So if that was the reason why you made a TUI, take heed. LLM's can chew through UI frameworks for you.
But I solidly believe TUIs are often better than GUIs even if they were equally easy to make. They liberate your app from having to follow the fracture and fashions of GUI's - Liquid glass, Windows 8, SwiftUI, WinUI3, QT, GTK or whatever. A TUI allows muscle memory that you learned on Solaris in the 90s to work fine in windows 11 in 2026.
tim-projects 3 days ago [-]
I'm currently building a winamp clone that works over ssh, using textual. So I'll have to hard disagree
stdatomic 2 days ago [-]
Sometimes I wonder if people are just writing these for the sake of having written something.
enthus1ast_ 3 days ago [-]
From tui i can copy (all) text and run it over ssh, only a good image protocol is missing for me
mcapodici 3 days ago [-]
TUIs allow you to have infinitely many running in tmux and also work over ssh so there is that.
lo0dot0 3 days ago [-]
Actual GUIs also work over the network, either as a web service rendered in the browser or a desktop app with a backend network connection.
rochak 4 days ago [-]
Or, you know what, don't listen to strangers on internet telling you what you should do. Do what you want.
theultdev 3 days ago [-]
You can't ssh into a swift app.
cush 3 days ago [-]
I wonder if devs are flocking to TUIs to gatekeep against normies building apps
archonis 3 days ago [-]
>> Because I assume that agents work better with a filesystem to grovel
What the what now?
yellow_lead 4 days ago [-]
This piece is just marketing for all the authors slop coded projects
ngvrnd 3 days ago [-]
user interfaces are for users. people who deal with words may prefer an advanced TUI. Others may find graphical interfaces more useful. describe, don't prescribe. let a thousand flowers bloom.
ewwefwef 3 days ago [-]
If your program use slow internet like tui I cant write tui program. no problem.
breppp 3 days ago [-]
TUI and Rust surged back in popularity when programmers through frameworks became detached from the actual work and needing to differentiate from all others in the even playing field. It's like turntables to Hipsters. Now with LLMs it is only going to get worse.
beardedwizard 2 days ago [-]
But TUIs make me feel smart, and my work feel important and esoteric.
migueldeicaza 3 days ago [-]
Make me
singpolyma3 3 days ago [-]
TUIs are just a kind of GUI. And rarely a particularly good kind
raincole 3 days ago [-]
Or, perhaps, stop making pomodoro apps, todo list apps with budgeting as their 'unique' killer feature, and damned Markdown viewers. Seriously.
plaidwombat 3 days ago [-]
Sorry, we Morlocks actually prefer the CLI to the TUI.
welwala 2 days ago [-]
I completely disagree. I love using TUIs, the apps are lighter and faster and work great.
The author starts with a bunch of vibecoded slop apps that show exactly what I hate about 'modern' GUI apps, a lack of options and wasted screen-space. They look hip but are harder to use to me.
Decabytes 3 days ago [-]
Isn’t the GUI version of a TUI just an Electron app?
imrebuild 3 days ago [-]
"But remember: I’m not really building applications for other people to use. I’m building them for me."
You are free to build anything you like, and whatever you build won't affect me at all.
jasonvorhe 2 days ago [-]
Stop telling people what to do (or not).
scythe 2 days ago [-]
>Finally, I can think of one strong argument for TUIs: they’re cross-platform.
>[...]
>But remember: I’m not really building applications for other people to use. I’m building them for me.
Giant caveat to the whole argument and it's buried 80% of the way down. Granted, he alludes to that a little earlier, but if other people using your application are a completely irrelevant outcome, you're an unusual case.
I mean, sure, I make tiny one-offs, but those barely even have something you could call a CLI. I push as much complexity into command-line options and config files as possible.
dolmen 3 days ago [-]
Another trend is to bring graphical features into terminal emulators thanks to the initial protocol and implementation work in Kitty with the Kitty Graphics Protocol.
https://sw.kovidgoyal.net/kitty/graphics-protocol/
And now libghostty has caught up with a full implementation of the protocol in a second terminal emulator. I guess that mitchellh has plans for use in Superlogical...
https://hachyderm.io/@mitchellh/117135178412268410
trollbridge 2 days ago [-]
LLM agent harnesses make it possible to do: CLI, TUI, REST API, web front end + Electron, native (I do macOS first, which then makes iOS/iPadOS almost trivial, followed by Android), and if I’m feeling ambitious, Windows (native) and Linux (usually Qt).
It’s much easier for the clanker to loop on testing / improving the TUI than a real GUI. It also means it can work on the app without an API/REST/HTTP/Java/Script ball of mud in the middle.
zahlman 2 days ago [-]
> I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful. You see where I’m going with this.
Does anyone else find that this reflects a really obnoxious attitude, regardless of whether it would work?
Anyway, it seems like the premise is that people would only ever build a TUI because making a GUI was hard, and now it isn't because LLM slop will be good enough. But I'm firmly convinced that fails on both counts.
seanclayton 3 days ago [-]
Ah, people who build and enjoy TUIs have never built a GUI. What a wonderful assumption to make about people :)
rafram 3 days ago [-]
The post doesn’t say that.
whartung 2 days ago [-]
I've mentioned this before, but the rise of the TUI is the simply the systemic failure of remote GUIs.
The primary value statement of TUIs is that they work over SSH with remote systems.
But now, we're hearing rumbles about the limitations of the "modern" terminals with regards to working well with a "rich" TUI. How a raw tty doesn't really cut it since it, at a minimum, can't detect key presses, only actual character/byte patterns. How there needs to be a new protocol, a "better" terminal client.
Of course when you go that route, then the current terminal emulators will need to be updated, or you'll be required to install a different terminal emulator that supports the new protocol. But that kind of defeats the theoretical, historical ubiquity of a TUI. It would not surprise me that many modern TUIs only work with an ANSI terminal.
Back in the day, we had systems like Visual Basic, Power Builder, SQLWindows. GUI/language systems particularly well suited for Client/Server DB development.
For a time, Firefox actually presented itself as a modern incarnation of these tools. Using XUL and JS for UI development, built in utilities to talk back to servers over HTTP. It was a platform for "Rich Internet Applications(tm)".
It didn't really take off, it wasn't documented very well, kind of buggy. It also required Firefox as a client. The potential was there, but not quite realized. Ajax hit the web browser in full force and that pretty much was the last nail. Now, you could use "any" browser for more interactive applications.
Of course, we advance to today, where many sites work in any browser as long as its Chrome. We have advanced applications that are no more than a Canvas element, with everything else being reinvented from scratch. "Have bitblt, will travel."
The browser is the closest thing we have to a universal remote GUI, but we all know the issues with it for many contexts. As an application platform, it may be ubiquitous, but that doesn't mean it's at all lightweight.
We used to have lightweight, remote GUI applications. Rootless X Window applications. Folk don't necessarily want the entire desktop, they just want an app, with some fields and buttons. You could slap them together with TCL/TK. Remember dtksh? We're not talking about trying to write Adobe Premiere or AutoCAD in these things. We just want some simple utilities, fields, icons, maybe a chart. Scrolling tables and a menu.
But we can't do that today, not readily, not easily.
So, we're kicked back to 1978 and the rise of the Smart Terminal, instead of 1984 and the rise of the X Terminal.
If folks are going to write out a custom client for a TUI, then may as well go the extra 10 feet and make it a remote GUI client. Reinvent all of the wheels as they go round, and round again.
joshka 2 days ago [-]
one step deeper - it's a failure of WIMP[1]. Imagine if instead of having a border around the parts of an app that make it an app and instead we applied the unix way but to the gui? What if we had lightweight widgets that had a lifetime of their own and could be nested and combined.
TUIs, at least to me and some friends in my circles, do something that native applications don’t: demand focus from the user.
Sure, modern terminals and TTY environments have visual tabs and virtual terminals that let you quickly toggle between multiple apps, and you can of course manually code your screen to split apps across a single “window” if you really want to get into the guts of things.
But for several folks in my close circles (myself included), the fact that each TUI occupies an entire screen by default, forces us to focus on what’s going on and what tasks we’re trying to accomplish in a way native UIs don’t. On the desktop I can flit between Discord and Telegram and multiple games and several Firefox windows full of tabs and the video encode I’m working on and hey did that bank transaction go through let’s check my email except UGH music streaming went off the rails so let me go back to my client and-
You get the idea. For folks who lack the neurotransmitters to maintain consistent focus or wave off distractions, a terminal environment acts as an accessibility device in and of itself. btop on 1, irssi on 2, Hermes (Qwen 35B) on 3, with 4 as my primary workspace and 5 as a fallback. Simple. Clean. Efficient. Lightweight.
I generally concur with the author that we should be “summoning” (I love that word for reasons that deserve their own essay/comment) more native UI apps that are as information-dense as, well, Bloomberg Terminal. There’s no reason we can’t build something as powerful and focused for the everyman for, say, inventory collections, or K8s constructs, or network architecture, all in a native UI. There’s nothing wrong with the GUI, only that at some point we let ourselves get suckered for the narrative that GUIs have to be easy, simple, and opaque, as opposed to transparent and (logically) complex. We can and should build GUIs that flow logically like the commands they’re executing behind the scenes; hell, we should be able to open a console log of every action we took in the GUI and the associated command(s) it executed, so we can better learn to transpose from GUI to CLI ourselves and build more capable or complex automations.
GUI isn’t bad. TUI isn’t bad. What’s bad is presuming one or the other is superior to everything (or for everyone) else, or worse, assuming one cannot function in a given way comparable or equivalent to the other.
rayiner 3 days ago [-]
I find it hilarious that Claude is still a piece of shit web app. Claude can just make apps! Why not release native ones? At least the TUI is pretty good.
weare138 1 days ago [-]
I would recommend OP delve into cross-platform desktop app development first...
evanjrowley 2 days ago [-]
I understand the point the article's making, and in fact, I believe it's a good one. Ultimately I continue to prefer TUIs over GUIs for one reason: Practically nobody will target TUIs for advertisements, doom scroll content, AI slop, any kind of marketing, etc.
Hizonner 4 days ago [-]
"Stop liking things I don't like!!"
calvinmorrison 2 days ago [-]
how about we stop making single window UIs
GreenSalem 4 days ago [-]
Incoherent and far too long .
Lists a bunch of things .
Fails to make any clear points .
Fails to give real reasons for the few claims it makes .
joshka 3 days ago [-]
I really liked this article (despite disagreeing with its conclusion and agreeing with many of the concerns about failures of TUIs). It gave a feeling of "here's a bunch of cool stuff I've done" to help back the claim, which is far more personal than a lot of blog posts tend to be.
jbstack 3 days ago [-]
Except there was nothing "cool" about them. Vibe-coding ugly looking GUIs with slop-code backends is not interesting or impressive in 2026. Literally anyone can do it, and I'm pretty sure 90% of HN readers are aware that it's possible. Plus it did nothing to further the claimed purpose of the article, which was to explain why you shouldn't make TUIs.
zombot 4 days ago [-]
But it makes some things very clear:
- All those GUI windows look the same. How the fuck do I tell one app from the other?
- The abysmal corner radii are a clear indication of terminal macOS. Pun fully intended.
PaulRobinson 4 days ago [-]
Building software for yourself - and only yourself - is a super-power.
I can see how LLMs help.
I wouldn't want to maintain software for other people entirely vibe coded. I think I might think again about native app development for my own needs, if it's kind of disposable.
dmos62 4 days ago [-]
Spent 2 minutes skimming, didn't manage to find a single talking point. I've no idea what the thesis is. Seemed like a list of things this person built.
People talk shit about LLM writing. Well, here's a prime example of why I like LLM-speak. Does this article have personality? Yes. Attitude? Yes. Is it structured and accessible? No.
I'll take clarity over personality any day of the week.
SpaceNugget 4 days ago [-]
That's a false dichotomy. If you launder rambling pointless prose through the llm you don't trade the personality of the writing for a well reasoned argument with clear points, you just lost the personality and gained shitty writing. LLMs aren't magic and can't make your point for you if you don't have one to begin with in the prompt. Garbage in garbage out.
dmos62 4 days ago [-]
I disagree. An editor can definitely make a piece of writing clearer without further input from the author. I often use an LLM to do that.
Of course, I didn't mean to imply that there's a dichotomy between personality and clarity. There's a dichotomy between ordinary LLM writing and personality.
mike_hearn 4 days ago [-]
Did you read it all the way to the end? It's coherent and does give real if debatable reasons for the claims it makes, I think it also does so quite clearly although if I'd written it the ordering of the sections would be different.
Here's an organically grown summary:
• TUIs suck because they are primitive, often buggy, hard to write and aren't accessible. Their existence isn't due to any real technical advantage but more because UNIX historically had a very bad UI toolkit (Motif) which established a 'culture' of TUIs.
• It's now easy (on macOS) to write native apps that use SwiftUI and give a much better GUI. You can just vibe code them.
• Some specific skills, features, templates etc are linked which look useful if you agree with this approach.
• You don't have to give up remote access because there's no reason the GUI has to run on the same machine as the thing it controls. A native GUI can just SSH in to a remote machine and run non-TUI CLI tools to control it. Lots of apps have worked this way and it functions fine.
• On the other hand, TUIs are portable (ish). The author concedes this may sometimes be useful.
jbstack 3 days ago [-]
> Did you read it all the way to the end? It's coherent ...
I prefer my articles to be coherent without having to wade through pages worth of irrelevant material.
theodric 2 days ago [-]
No. In fact, I will make another TUI just to spite this article. Maybe two.
dionian 3 days ago [-]
for me : make TUIs and GUIs.
frou_dh 3 days ago [-]
The typical TUI fan is a nerd with no clue about typography so therefore they don't notice any problem with being shown elements that have no reason to be monospaced in monospace.
i.e. ignorance is bliss in the world of typography.
Gormo 2 days ago [-]
Perhaps the average TUI fan is someone who correctly recognizes the negligible relevance of typography in optimizing their computing workflows, and prefers monospace fonts for purely functional reasons, which naturally take precedence over merely aesthetic concerns when working with functional tools.
The total abandonment of the form-follows-function principle on the part of purely visual designers, who worry about what software looks like without considering what it's for, has led to 10-15 years of cumulative usability degradation in almost all categories of software. TUI and CLI software remains one of the last bastions of people actually designing interfaces for functionality and usability.
frou_dh 2 days ago [-]
You can't dismiss typography as irrelevant and trivial aesthetics. It's a whole field encompassing many things including legibility to humans. There's nothing more "functional" than principled crafting of legibility for each UI element. And no, a crude "Just use the same font in a single size for everything" approach is not the endgame for legibility.
Just because there have been some crappy industry trends doesn't mean the answer is to turn away and permanently regress to the confines of a terminal emulator.
Gormo 1 days ago [-]
> You can't dismiss typography as irrelevant and trivial aesthetic.
Sure I can. That's not to say that it's completely useless and not worthy of any attention at all, just that it is far removed from the primary considerations of software design -- it absolutely is an aesthetic matter that is not an important consideration until functional design is settled.
formvoltron 2 days ago [-]
curses!
the_hoser 3 days ago [-]
Never.
guax 3 days ago [-]
No
yoz-y 3 days ago [-]
Make guis where guis make sense. I, for one, like to stay in my tmux session as much as possible.
And sure, for programs for one go ham on the ui.
qsera 4 days ago [-]
Do more TUIs. Please.
himata4113 3 days ago [-]
I feel like this is the typical MacOS user stereotype.. Cosmetics over efficiency.
No, for the love of god never stop making TUI's.
rvz 3 days ago [-]
Old man yells at terminal.
Who tf cares about what the author who appears to be new to building native desktop apps (and vibe codes them) says about terminal apps?
I am not writing my code 3 times for each native platform even for agents and then dealing with signing keys just for it to break on a OS update. Terminal apps for developers survive all of this.
The entire article is just a massive rant with woefully weak points. I guess agents really does amplifies both Gell-Mann Amnesia and Dunning-Kruger in others.
qiine 2 days ago [-]
nuuu
newtonianrules 3 days ago [-]
No.
ewy1 3 days ago [-]
this blog post is mostly shadowboxing and showing off their llm-made software; kind of disappointing
z3c0 3 days ago [-]
Yeah, the holier-than-thou vibe-coder is a new cliche I'm not enjoying.
tptacek 2 days ago [-]
I don't like TUIs. And, having built several, and then having the experience of building meaningfully complex native UI for the first time in my career, I couldn't help noticing how much of the tedious work of putting a TUI together, even with a good framework, is already solved (and solved well) by the native framework. TUIs force you to implement things native UI developers aren't supposed to fuck with at all. That was radicalizing for me.
So one reason to write this post is just to send a bulletin to developers like me, for whom it wouldn't have even occurred to build native UI before. Native UI is now a thoroughly solved problem. All "off the rack" user interface is solved now.
But that's not the biggest thing happening here.
What's really going to destabilize us is what this says about computer usage and computer programming. When I was a little kid, in the mid-1980s, I imagined all sorts of new different things I could do with a computer, if we ever got one besides the ZX81 clone that plugged into our TV.
I had to grow up to become a computer programmer to learn that one doesn't simply tell a computer to do new things, that there's an elaborate ritual to build anything useful, and it takes years to get comfortable with those rituals. And like most other programmers, and really craftspeople of all stripes, I came to appreciate the rituals and the specialized knowledge. They're part of my identity, so I tend not to question them.
But there's always been this dividing line between computer users and computer programmers. It's rarely disrupted. It happened once with spreadsheets (our profession has a sort of Kubler-Ross thing going on with the fact that Excel formulae are the world's most important programming language), and maybe just a little bit with HTML in the early web. Other than that, we've all been pretty siloed.
That's obviously about to change, in a more significant way than it ever has before. Computers are going to work the way I assumed they did when I was 7. The line between programmer and power user is going to dissolve.
I'm not interested in what that does to our profession or the question of whether or not there will always be a need for serious software craft or engineering or whatnot. Totally valid question, but not where I'm coming from.
I'm interested in what systems look like in this new world we're heading into. What is an operating system in a world where most applications are summoned by the person who's going to use them? What even is an application at that point? What are the interface idioms when we're truly no longer constrained by text inputs to compilers and program building tools? Does everything look more like Smalltalk? Like a Lisp Machine? Or like something weirder? It's gotta be something. It can't possibly be the case that the shape of computing we all count on today is going to survive the next 15 years; it'd be like driving steam-powered automobiles.
That's the fun question.
rrr_oh_man 2 days ago [-]
This reeks of AI slop.
> Our field has a weird relationship with terminal and command line interfaces. The time has come to re-evaluate it.
Why? Why is infatuation weird? Why should we reevaluate it? The whole premise sounds like a "give me a hot take on XYZ".
(I built itter.sh so I'm biased)
vladshiyan 2 days ago [-]
[flagged]
mkayokay 3 days ago [-]
[dead]
m463 2 days ago [-]
The root cause of TUIs is keyboards. We should deprecate them and achieve the death of TUIs.
/s
likeclockwork 3 days ago [-]
No.
shevy-java 3 days ago [-]
> Which is why I would never hand-write this program. Instead, I summoned it.
AI slop spam.
I don't want to use those AI sloppers. They often are not based on any intelligent design.
A good counter example is, in my opinion, htop. Many people use it, despite its ncurses-nature. It simply does what it wants to do well: give an overview over resource usage.
Yes, AI slop can spam-generate a clone, but why would I want to use that over the real thing? It makes no sense.
> I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful.
I don't want this spam slop anyway, but notice that the author became super-lazy. Rather than providing source code, he tells you to copy/clone it via Claude spam. So this human is now too lazy to do anything useful. Skynet won. He has been AI slop spam absorbed, without even noticing. Just like in the movie Invasion of the body snatcher (great movie, both the original and the first remake, though I liked the remake more, because Sutherland was in his prime back then).
The author continues to show more AI slop spam created useless things. None of which is interesting. I am surprised people now blog about boring AI created software and call it engineering. So, nah, don't stop making TUIs. Instead, design them better.
Having said that, I think ncurses is the wrong tool in general. We need to be able to design both TUIs and GUIs in one go without barriers. Every time I have to use ncurses, I do indeed curse.
brazukadev 3 days ago [-]
> I don't want this spam slop anyway, but notice that the author became super-lazy. Rather than providing source code, he tells you to copy/clone it via Claude spam. So this human is now too lazy to do anything useful. Skynet won. He has been AI slop spam absorbed, without even noticing.
and it "worked" - the audience he found for this is bigger than the previous one. So this continues until the AI psychosis become so high it start to turn people off.
dekdrop 3 days ago [-]
TUIs are popular because Unix didn't have graphics. Plan9 had graphics but didn't catch on. Making us living in an emulated terminal device.
sgt 3 days ago [-]
Oh dear, the comments here are a bit disturbing and hilarious. The "Linux" mindset simply does not comprehend that proper UI's can still be made. Maybe that also includes the Windows mindset these days. Most of us macOS users never rejected TUI's, but we always had world class GUI's.
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.
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 thought Claude could do anything nowadays.
Querying into the DOM and working off of that means you're not futzing about holding onto a bunch of component references for the one thing you might need later on.
Web layout is also pretty easy to just get right, native GUI frameworks have a different kind of layout model that is not as amenable to "arbitrary" data (at least at first blush).
the reactive programming model also works quite well. While there are native GUI frameworks that lean into reactive programming, they tend to be doing a bunch of weird stuff that cause other issues.
And at the end of the day, when you package something like a Qt app it still often ends up being quite chunky.
In the end tho... the simplest thing is if you do web stack you get a web UI _and_ your "native" GUI in one go. Build things once, not twice. Hard to argue against that when that's presented.
Mobile has significant paradigm changes that makes using both terminals and traditional GUIs harder anyway though. I do expect the need for completely different cross-platform libraries for mobile UIs.
Also, Qt does support Android development.
The official NDK documentation on what is supported for NDK written code on non rooted devices, and the hurdles that Termux faces to keep running on standard Android images via PlayStore distribution, show why it isn't right.
> 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.
In any case we can surely do better than emulating DEC hardware from 50 years ago.
I expanded on this point nearby: https://news.ycombinator.com/item?id=49400697
I think this is slightly wrong in two ways.
i) If you want platform native then reimplement the gui on every target platform. It’s as ”simple” as that.
If you need to ship to multiple platforms then preferably you need lots of plarform specific engineering in any case.
”I just want my hobby tool” scenario likely does not require cross platform support unless there is market for it. I mean rather than offering the tool on multiple platforms it should be offered on multiple languages first, perhaps. As soon as you are not writing the tool for yourself we are talking markets and distribution. Likely most people can chill out and just implement the gui for themselves (and not even publish it in githubb).
ii) cross platform quick-and-dirty way. Without screenreader support, multiple language and glyph support etc. Game ui:s look the same on all platforms. Websites look the same on all platforms.
There is place and time for deep ui engineering that respects the _critical_ cross platform issues like accessibility (screen readers etc) and different languages and scripts.
And then there is the situation where you want just few images to click. The latter is vastly simpler, fast and fun. But harder to convert to a professional quality gui experience. For small tools and MVPs this sounds like a fair tradeoff.
TUIs look bad everywhere, so that's strictly worse
I would definitely be pro minimalist unicode-character-themed GUIs for what it's worth. Where every graphical primitive is basically a unicode character, without the restriction on font size.
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.
https://ratatui.rs/concepts/backends/mouse-capture/
https://en.wikipedia.org/wiki/Turbo_Vision
sounds like your terminal emulator is just crap, terminal and iterm on mac just work
If you mean what Claude Code does when you paste longer text, you can just press Cmd-V again to show the full text.
And if you meant "virtual machine" or "cloud" by saying "container", `waypipe ssh myhost`.
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.
Especially when I keep bumping into Electron apps.
You can make slow things with it of course but it's not inherent.
http://foo.wyrd.name/en:bearlibterminal
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.
[0] https://github.com/ocornut/imgui
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.
So: http://claudecode.local
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.
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.
Yeah, in my hypothetical new protocol, the character cell is still there, but it's not the element that drives the main abstraction. The layer above that being more semantic is where the smarts is. So borders, interactive areas, mouse hit mapping to elements, etc. ends up being built into the protocol rather than being a cell level thing. Cells having proper borders being similar to how they allow for underline, being able to have both images and text, ...
I think it's important to do something about the VT100 +kitchen sink stack and to have that as something that still works with that in areas of the new terminal proto. I've got a slopcoded rust library in the works that's about fully mapping the full list of terminal protocols and related things in one coherent library (VT100, ECMA48, DEC modes, iTerm extensions, Kitty, ...). From there I think making that fairly isomorphic with the terminal emulator layer (I have a RIIR ghostty slopfactor there too that fits).
I think ghostty / superlogical looks at this from the perspective of doing pty things and then transfering that calculated state across the wire while doing fun stuff with windows, panes etc. with replay and that sort of thing. I think this is valuable too.
I suspect that there's possibly a way to do a bit of a hybrid on this - normal pty things with the extra sidecar of more semantic structured, but it'll make things more complex for app builders on that side of things.
(On another comment I saw you mentioned "couldn't help noticing how much of the tedious work of putting a TUI together". I think probably textual in python is probably the best of the low ceremony libraries for making TUIs if you haven't checked that out yet. I think someday there will be a good Rust library that has that level of put together-ness. I have some ideas on this for ratatui and have seen a bunch of things that are directionally right for this, but nothing that gets close yet).
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.
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.
From what I undestand, the terminal is essentially a concatenative text buffer extended with control commands allowing you to move the cursor (pen) to draw more sophisticated stuff, and update UIs.
The logical way to extend this would be to allow genericdrawing commands over the protocol, at which point the whole thing starts sounding like X11.
I'm sure the Unix people at MIT in the 80s saw this as the natural evolution from text terminals to graphics based ones.
Not saying this is a bad idea, but sounds suspiciously like a retread of history.
Or you might want to stop before that, as you suggested, at targeting fixed size cells for rendering, and keeping the console-like UX throughout. I'm sure there's a sensible intermediate step, but if you want to do things like displaying graphs or images (turning the terminal into something that's halfway between a terminal emulator and a Jupyter notebook), it'd be awkward to respect the character grid and the non-square characters themselves.
I'm curious what you think about how far this new protocol should go, and in what direction. You mention 'semantics', as describing behavior, not just what gets drawn to the screen, which neither X11 nor tty does.
Not sure how you're planning on doing that, can you incrementally extend the current model, or will it require a completely new protocol?
I don't know why Codex and Claude Code haven't switched over; both apps have a terrible UI in comparison.
There's a lot of things you can do to get to 90-95% fidelity with a normal scollable terminal, but that last 5-10% is impossible. And it's because the you're throwing away a bunch of information about mouse movements, clicks, scrolling, keyboard on the input side and all the layout info on the output side (the terminal just sees cells, locations, etc.).
A good analogy is what if your webserver could only send pixels, not html. And receive raw mouse movements. The amount of stuff you have to do to reconcile that across operating systems and hardware would be enormous. That's what you realistically have when you're writing a tool that reimplements all the bits from a terminal emulator in a tui.
https://interlisp.org
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).
[0] https://neovim.io
[1] https://github.com/jrop/morph.nvim
[2] https://github.com/jrop/tuis.nvim
> 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.
All that is not true. Take scrolling for example. Each terminal emulator implements this subtly differently (mouse/trackpad/speed etc.), scrolling will never feel native unless you push the control of it into the terminal emulator.
There's more than that, each and every point on this becomes something that you have a gap between native and the terminal emulator that you're building to run in the terminal.
See https://github.com/openai/codex/issues/8344 and https://github.com/openai/codex/pull/9640
Claude code and gemini have both had various versions of the same idea at times. I'm unsure where they ended up.
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.
[1] https://github.com/ricardobeat/milktea
Especially becuase TUIs doesn't really have any of good properties that a CLI offers such as composebility. It's still a fixed UI with panes and menus which has just been squeezed into a character grid, and now forces the user to learn its pre-set keyboard bindings (which surely can be changed, but with every app having it's own config managment).
It's kinda the worst of both worlds to me. Either go all in and give me a proper text-based interface like Emacs (where you can globally configure how you wanna deal with lists of text in buffers), or just make a proper GUI with good keyboard support.
What was worse was their mouse platform wasn't level. So every time they let go, it would drift downwards and they'd have to go through the "where's my mouse pointer" wiggle again.
The way the whole industry adopted it is understandable given the install base, but it's also probably a trillion dollar tax. I'd hate to see how much additional energy is used by billions of end-user devices running a rendering layer that is 100X heavier and more CPU intensive than anything native or TUI.
There should be public browsers and public search engines. The private incentives are too much and software built for public needs can be extremely cheaper than their private counterparts once you remove the need to support advertising services.
Consider this: Grocery store cashier interfaces are graphical these days, yet they're still optimized for fast input.
They're wannabe window managers.
VSCode SSH extension is one of the most widely developer-used proof against this. Windows' RDP is the other one where many engineers and POS personnel have experince using them. Many electrical and mechanical engineers still use Windows RDP at my work to run simulations. The connection is responsive enough to survive their home-to-office VPN connection. I set up complex chemical simulation software that is accessed by clients of a HPC cluster over 1000s of kms away.
VScode has a really efficient protocol that communicates only that's required, Windows RDP can declaratively send UI component changes as long as one uses Win32 or WPF. It can also reasonably compress the data to even survive dial-up levels of bad data.
We use multi-attendant video conferencing day to day with whiteboarding extensions. If there is will, efficient and amazing remote-GUIs are easy.
Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.
Genuine question, what is your alternative suggestion to accessing lower level features then? A hard time I have with GUIs is that their input/output can't be piped. It's much more cumbersome to try to automate a GUI than to automate something in the terminal.
Whilst I get that this is about TUIs, I do believe there is a reason for shell access due to automation. Good abstractions can be put into the GUI, but I'd argue that you should first build the abstraction, then put a GUI on top of it. AWS is a prime example, any of their APIs can be used w/out AWS Console.
devdraw can be thought of as a 2D rendering engine. You load assets like text, bitmaps and so on then issue draw commands to render them. There is no SSH. Instead you connect to a remote machine and export resources served by your local machine including your keyboard, mouse and display, each of which is a network transparent microservice. The window manager, Rio (and others), multiplexes access to these microservices. You can run a graphical program without a window manager, e.g. you can boot right into Doom or the Acme editor. It's seamless and can run over any pipe that can push 9P including ssh. If you look at the Sam and Acme text editors you will find they are true modern TUI programs.
Shame we had a cloud ready OS for 35+ years and no one noticed. Instead were living in the 60's with GPU accelerated typewriter emulators.
However I would rather prefer its successor, with Limbo for userspace, although probably not Tk as the main UI toolkit.
The terminal thing emulating typewriter are a UNIX thing, as other graphical OSes, presented a plain REPL, or graphical shell, e.g. Amiga DOS did not emulate any tty.
Otherwise I agree with the spirit of the comment.
Since when is pipelining a low level feature?
How do you think OSes like Mac OS (the original one), exposed their low level features, whatever that may be?
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.
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.
What do you run like that day to day?
Waypipe is production ready & easy to use. If there doesn't exist a program making use of it for the average user, then it's because nobody saw a it as a solution for any occurring problem yet.
When I moved from DOS to Linux, I chuck away TUI file managers and switched to pure CLI and never looked back. I could use GUI file manager, there you can really use mouse, without that jumpy-movements it has in TUI apps. But I wouldn't touch Midnight Commander or whatever.
I tried to run emacs in a terminal. Emacs' support of GUI toolkits is very cumbersome thing. But guess what forced me to abandon this experiment? Emacs is keyboard-driven, and terminals have issues with some keys, while GUI apps can deal with virtually anything.
> If we had a cross-platform usable GUI framework, and more consistency across OSes, the story would be different.
Try egui. I really like it. I'm not sure how much it is cross-platform though, hadn't tried it outside of Linux, but it is really nice. Or if you are an elm-purist then iced might be your choice. Iced lacks on widgets, it has just some basic ones, and if you need something to render a 2d-plot, then you are on your own.
I could swear there once was a (n)curses or otherwise text based GTK+ implementation / backend. It didn't do everything of course, and this was, I don't know, about 2003-2007, but you could compile a GTK application and run it in the console.
I tried finding a link, but unfortunately could not, can't even remember the name, I only remember building a piece of software that way that did GUI or TUI depending on how it was linked.
https://github.com/libyui/libyui
https://yast.opensuse.org/
https://lwn.net/Articles/1080821/
My big beef is the dichotomy of today's GPU accelerated bit-mapped displays which are burdened with this silly task of running a program that emulates a typewriter. Why TF do we not have a display protocol that can do graphics natively over SSH in 2026?
> TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input.
This assumes a typewriter emulator. Why are we not working on graphical systems where text is a first class primitive allowing us to easily draw text in any color, font, size, formatting and orientation as we please, onto a GPU accelerated display? Keyboard can still reign supreme. No mouse needed but if it is - first class support unlike crappy typewriter emulators.
Did you mean X server?
X is well past its sell-by date.
Plan 9 is text first as it was written by Unix programmers who wanted to build an OS and write programs (Rob wanted a better text editor.) It's the OG TUI. Window managers like Rio can run in Rio. You control things by writing textual messages from the command line, scripts, or code, e.g 'echo 100 >/dev/volume' to set audio volume to 100%. Someone wrote a new WM called Lola so I ran Lola in Rio in Lola in Rio because I can. Sam is very much a keyboard driven modern TUI ed (the standard editor). Acme is a mouse driven TUI editor. Both can be automated by programs and scripts. You can edit text while reading your email and chatting on irc from within Acme.
BUT Lots of stuff missing. We don't yet have GPU accel. It's a MSSIVE undertaking. And it has to be carefully designed and would likely be a built around a generalized devcompute kernel device.
Here's an example I just pulled out of my shell history:
This huge oneliner clears the screen, logs into my laptop via ssh, then logs into my development virtual machine, then generates a patch from the specified commit, and this data gets piped into my Termux terminal and my phone's clipboard. Then I paste it into the ChatGPT app for code review.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.
https://contemporary-home-computing.org/RUE/
Except for, you know, every serious professional application ever.
I was visiting a radio test lab in last February for our new product. They use a professional software which was written in WPF. The assistant there was flying with the keyboard shortcuts.
I recommend every self-describing Unix or terminal fan to watch videos of photo or video editors / VFX people on YouTube. They are hella fast.
Another example from recent history, I just wanted a easy way to mount all connected drives, so whipped up:
How would you even approach this with a GUI? You'd need something like Automator or whatever is called on macOS, then manually pipe GUI elements together (or some other way?), and finally there is no automated way of actually testing that it works, so once it breaks because the inevitable OS upgrade, you'll need to manually fix it. Then whatever solution you came up with or used, is almost never reusable for other things.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.
Isn't it against both? Maybe I'm reading it wrong then, because things like these certainly seem against CLIs:
> Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing industry on their shoulders.
> If you haven’t tried your hand at turning one of your 500 throwaway CLIs into a native app, you’re doing yourself a disservice.
Maybe I'm missed something else, but I certainly got the impression the author isn't very impressed by CLIs.
> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.
+ 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.
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.
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.
They're an absolute torture to work with over a dodgy connection, which often may not even be your fault. Looking at you AWS.
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).
https://en.wikipedia.org/wiki/IBM_Common_User_Access
I think the real problem is as computers have become more mainstream, they've become more subject to whims of fashion. Consumer-focused companies don't want to be seen wearing last season's UI paradigm. Just watch Apple change things around...
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.
FWIW, most of Windows XP's utilities and included software was perfectly usable with a keyboard alone.
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.
The problem is discoverability. You need to go out of your way to learn shortcuts.
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).
Meanwhile a GUI's developer has to decide to grace me with the ability to even open more than one window. "A tabbed interface will be sufficient!" -- yay, I'll never be able to view two screens of info at the same time.
It's not true for AppKit, SwiftUI, GTK, Qt, WinUI, or Electron, and I'm not sure what's left.
https://www.electronjs.org/docs/latest/api/app#apprequestsin...
and handle this event:
https://www.electronjs.org/docs/latest/api/app#event-second-...
I believe macos is the only OS that enforces single instance by default. If you start xterm five times on linux, you get five independent xterm processes.
It looks like macOS Finder tries to make it difficult to run two copies of a .app simultaneously, so I imagine many programs don't check for this case, but this is Hacker News, so we can use our hacker skills to try and do what they don't want us to: find the exe inside the bundle and run it directly from Finder, or run it from the terminal using its path. (This works for me with Ptacek's mdv app. Two copies of it end up in the dock.)
vscode, electron app, no problem opening multiple windows. Geany, gtk app, no problem opening multiple windows.
Can you give an example where this doesn't work?
But the point is that the developer has to build the app in a way that lets you do this.
Once again, there is no default with the tools I listed. You decide on how you want windowing to work and then build it.
At this point, show me examples of needing a mutex to "block" a multi-window default.
Just like you can start vim several times you can start gvim several times and have a few windows. This is the default behavior, and if the developer wants to change this for some reason, they need to put in some effort.
Maybe macOS is special? I'm not familiar with this platform.
You're wrong about GTK, Qt, WinUI and Electron though. They default to "do nothing" which eliminates the ability to even know that another instance exists. You have to manually program that.
Even in SwiftUI which has the simplest way to support multiple windows with zero work, the developer has to use WindowGroup, and if they didn't then you don't get to open more than one window.
The merging behaviour is also in principle possible for TUIs, btw, it's just that nobody does it. But with something like tmux is would be easy to set up that all subsequent calls to your binary actually connect to the already open session launched by the first instance.
TUI apps are multi-instance by default since the user can invoke the program in different pty sessions. The developer would have to actively fight that.
GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window.
Whether things might change in the future isn't relevant because we're talking about how things are today, not speculating about the future. And the time to change one's opinion is when reality changes, not ahead of time based on how you think things hopefully will be.
I don't know which GUIs you have programmed but for Windows and GNU/Linux this isn't the simplest option. It requires quite the effort to actually enforce single instance.
For a TUI to do the same, it wouldn’t just need to find and focus the window, but would need to trace it through the myriad ways that a TUI can be displayed. I may run a TUI inside a docker container, as part of a tmux session, over ssh. If a TUI somehow managed to focus the existing instance through those layers of wrapping, I would be very surprised, disgusted, and impressed.
So I think it’s that the end goal of “redirect user to existing instance” is infeasible, so nobody bothers to enforce a single instance, since the rest of the steps aren’t possible.
Emacs Server and tmux would both like a word. Make the current tty show the app output.
Pretty much all GUI frameworks I have worked with behave the same, and you have to actively create singleton behavior.
Then you have Mac OS which makes it hard two create multiple processes of a GUI app. Other OSs don't necessarily behave the same.
There is an opencode plugin for this opencode-pty.
Terminals + browsers is all I want for most apps.
Native GTK/QT is really good, but I only want it for "system" things like a clipboard manager or file manager settings app and things like that.
But I don't think I've run into a TUI that I couldn't have multiple instances of.
https://en.wikipedia.org/wiki/Tab_(interface)
Same with docker containers
Same with concurrency
Same with Notepad
Same with exec
Same with bsd jails
Same with copies of data in a for loop
Same with recursive functions
Same with numerous copies of image viewers showing the same jpg and txt files
...it's all arbitrary containers and arbitrary recipes to encode and decode binary
They are usually tied to specific user accounts, it's true. But that's something some people made up, and it doesn't have to be that way.
Imagine if there were no terminal/pty system. Then what, I'd have to use Claude Desktop (doesn't support multiple windows) and Finder?
So no, it's not the only argument for TUIs.
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.
We are users.
> Why can't developers understanding that GUIs and TUIs both have their usage, it just depends on the task?
Isn't that the case for most TUI apps? They tend to serve quite specific purposes. Nobody writes a WYSIWYG word processor in a TUI. Because you can't and even if you could somehow with sixels it would work horribly bad.
In a dual role, I would say that the most impactful aspect (being a developer) matters more.
> Nobody writes a WYSIWYG word processor in a TUI.
But at the same time people write all sorts of other apps that could hugely benefit from a GUI. I seems like if the output itself is not graphical, TUI-enthusiasts won't acknowledge the advantages of a GUI layer, while only bringing in arguments why they can implemented poorly.
GUIs have a much higher surface to be done wrong, so standards are higher. But there's still a decision that needs to be weighed carefully, and many developers seems to simply jump on the TUI bandwagon just because it's easier.
But a TUI needs dedicated understanding of terminal toolkits. That's not easy. A GUI is much more easy mode with electron, a bit of javascript and a GUI toolkit to design the UI, easy peasy. To me the TUI is the hard option.
I really enjoy TUIs though. I wish there was something like vscode in TUI. I like the responsiveness and the no-nonsense. No logos and other commercial bullshit, no huge amounts of whitespace that UX designers consider "best practice", just highly dense data.
Also, I've worked with some of these designers and their holy best industry practices have nothing to do with anything that benefits the user. They're all like: "Is the logo clear enough", "Does the user get drawn to the parts that make us the most money (like ads or premium articles)", "Is the user finding the thing we want to promote".
To me all websites should look like Hacker News does. Not like a "modern" newspaper site does.
As far as I can tell, practically everyone arguing for TUIs thinks Claude Code is a horrible example.
Once you go down this path, it is hard to go back. Very few tasks, apart from things like Photoshop and Revit, really require me to be at a GUI these days. And with MCP a lot of that is going away.
Now I use Codex UI which is miles better than any other tool I used.
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
I love a GUI in many cases! But if I'm building something, I personally want it across Linux and MacOS at least (personal and work, respectively). TUI answers that problem quickly, easily, effectively, and efficiently.
I'm actually amazed that we have never gotten to a really good UI framework that is cross platform. I really just want something like SwiftUI that's truly cross platform, personally. There are a million arguments to say that we do have cross platform GUIs, but all of them lack in some major way.
Just curious re: the obvious example of "The Web" - do you consider it "not good" or "not really a cross-platform UI framework" as such?
It's also generally resource intensive, compared to a solid native UI.
I would say that, if you don't need more native control, the web is the best cross platform interface we have, by far. But not having those system API really starts to limit it for certain tasks IMO.
When I just want a graphical utility, I build a single HTML file that includes all of the assets required, and all of the JavaScript so I can run it offline (but generally host them on my site so I can get to them from anywhere). These tools are generally text in and text out that I want a GUI representation for and don't need in the terminal.
One example - wxWidgets exist, and wxDart exist, but getting to something half as usable as Flutter from there is almost impossible. I defy you to even build a layout engine that works on all three platforms. After that, you still have to find answers for theming, spacing, responsive behavior, component composition, inspection/debugging, hot reload, accessibility conventions and on and on.
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. :^)
That's awesome, I have one too and I fell in love with it. I fixed up the old gif320 program to run properly on modern machines a while ago and made a C# port too:
https://github.com/ldyeax/gif320
https://github.com/ldyeax/Gif320Sharp/
How do you deal with modern programs not respecting TERM/LANG capabilities? I found even using man pages on my machine would sometimes result in the terminal getting caught up on some invalid byte sequence emitted from some unicode that snuck its way through or such.
I ended up writing a program I called VT320 Translator, or vt320t for the name of the binary, which in broad strokes runs your target program in a background terminal and sends curated updates to the VT320 while passing through keyboard input. (You can kind of approximate this with just screen and some other things but it doesn't end up being very good IME) This lets me do some neat things like translate unicode characters into DRCS (Dynamically Redefined Character Set) sequences that you can actually see on the VT320, use optimized heuristics for screen updates tuned to the exact hardware, etc.
At the core is a vtparse-based VT320 emulator that strives to be as accurate as possible with an accompanying diff generator from one emulator state to another. If you're interested I could get into more of what I've done here and even get the code onto my github - it's been private for a while because it's being used in an upcoming game demo but I could easily separate out the non-game-related parts that make up vt320t.
On the Linux/BSD side, most toolkits are of not great quality, you'll inherit all sorts of subtle bugs and quirky behaviours. Most of the software that's of _great_ quality doesn't use the toolkit, but interfaces with the compositor directly. The effort for developing GUIs under such circumstances is dramatically higher than a TUI, and a TUI is usually "good enough".
I really would prefer GUIs for a lot of things. But when a TUI takes a few weeks to make, the equivalent GUI would take a few months to make.
Flutter is an absolute nightmare to install and work with. Even now the few bleeding-edge distributions where it's available are lagging behind many releases because of the pain that it is to maintain it. I don't want that level of pain as a pre-condition to building my software.
Good luck exhausting Claude. As long as you keep feeding in quarters, it will keep hacking Qt.
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.
I will just stop here. No hates for macs, but your typical cli/tui software devoper is concerned about making their software run on almost anything with an actual os. As soon as I see references to specific operating systems or platform specific libraries my bullshit meter goes off.
I was expecting an article about methology and tooling to develop guis, got an apple fan telling stories about ai use.
Let say someone, as windows or linux user, clicks on this article claiming he/she should stop "doing TUIs", what take away message should he get from it? "GUIs just looks nice but sucks you have no swiftui"? Personally, I was expecting a developer's angle on GUI programming.
>But remember: I’m not really building applications for other people to use. I’m building them for me.
What's the point then? What's the point of writing an entire argument proselytizing towards application developers and ending with saying you're only talking about applications you're writing for yourself?
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
Why? Because just look at the examples on that page.
Or for Go coders there's BubbleTea: https://github.com/charmbracelet/bubbletea
Why? Because TUI!
Please, don't. One of the main benefits of TUI is being able to freely copy text, I hate opening Textual application and being dropped into this canvas like state.
I guess it’s a matter of taste ¯\＿(ツ)＿/¯
I love the visual style. It's especially interesting to set the colour scheme to the orange/yellow glow of reaaaly old school terminals.
Apple deprecated carbon (which was a thing when gtk1 was around). I don't think you have an option for this on their ARM hardware.
QT1->N code has the same problem, the older libraries are not shipped on most modern linux.
I do absolutely understand if you're going to do static compiles, that can work around that problem, but that arguement nullifies everything, since you can run/write/execute anything in a turing complete system, if you complain you're just not dedicated enough.
y'all are slow learners if that's an issue for you, but React doing major breaking changes at least once a year is totally fine.
No they don't. Many components are SwiftUI only.
The same reason webui and js is so popular!
Once we have robust automated computer use, that becomes the verification loop, and this problem will almost surely get solved.
This pretense that the entire value of source code is the "spec" / "requirement" is alarming.
The value of the code is how well-formed the spec is + how well tested it is in the real world. So prompt / mockup cannot replace code.
Sure, an LLM can fix it, but that assumes your original spec sufficiently described the user requirements and wasn’t just a transcript of the original session trying to figure out how how to interface with all those dependencies in the first place.
The one advantage that a terminal has, is that commands can be concise and scriptable. But that only really applies to CLI.
A TUI is just a poor man emulation of a GUI, without any advantages.
I salute you, heros.
Please, make more TUIs and web apps, so they can live in my terminal or my browser.
Once you get the key bindings for screen or tmux thoroughly memorized it's very easy.
I have a windows box that never shuts down and i remote into it and use it GUI mode to do everything you said but with a proper GUI interface. I also use the terminal but your feature (constantly up + resume + multi device) does not need TUIs to even work.
[1] https://github.com/charmbracelet/bubbletea
[2] https://github.com/charmbracelet/wish
And you present the division of this simple unification of modalities as a benefit, but don't explain why it ought be many.
So far it's all just preference.
I'm not going to deny that the terminal has a ramp, is a lifelong learning curve. But I personally find it much more earnest, much closer to what is really happening, with less intermediation, and the way that terminal conposes with other things is usually unbeatable. TUI for humans, jsonl event sourcing for machine-to-machine.
> drawing on a couple of decades of established UX conventions for how they are displayed
I tend to not just click random apps open. I tend to have done some research and found what options there are on my own. I tend to know what I'm looking for, by the time I'm going to run something. In terms of getting there, finding stuff: the best convention I know of is aptitude, and dselect before it. Both very fine very old tui systems, and clear cuts above any app or web store, imo, for its power, directness, clarity, intent, and script ability.
While a mouse can theoretically use all pixels of a screen, in practical terms a keyboard has a much larger input space than a mouse, and if I can keep both my hands on the keyboard, I can work a lot faster.
At least that's my experience as a (starting) greybeard.
But with a worse UX?
As a devils advocate in response to all the comments claiming TUIs are fine, maybe consider TUIs mostly do not come with many of the advantages of using a terminal CLI app - you can't pipe data into them, out of them, spawn them and collect the output, etc like you can with the usual stuff you run in a terminal.
IOW, they are a reduced functionality of a GUI - resizing works poorly, scrolling works poorly, UI affordances are poor (sure, you can grey out a button, but drag-n-drop hardly ever works between your various terminal tabs, and the smallest UI element is a full character block, unlike a GUI where you can have indicators that are smaller than a character, mini-windows, etc), lack of widgets, etc.
The lightweight argument is not so good either - look at Claude Code, after all. If you want lightweight GUIs, you can do that too.
The only argument that stands is the ssh one, but if working via a remote connection, I'm not going to want a full functionality application anyway - why would I prefer a wordstar/wordperfect interface to a complex document over a GUI interface? For simple documents, sure, TUI all the way, but when I have multiple panes (outline, minimap, status bars, toolbars, etc), it performs poorly in a TUI.
TUIs are making a resurgence, sure, but only in the context of developers and development.
Native UIs simply don't have the same flexibility.
Edit to add: I didn't bring my laptop; I'm working from Termux. Surprisingly effective! The code is all in a folder syncing with my phone via SyncThing, so I can try out the sites I'm working on directly on the phone.
So you can't even immediately switch to your app and don't see it in an OS-integrated list?
My reaction to this is basically about the same as the fictional Ivan Chesnokov
(beware, crude language, profanity, etc)
https://m1-garand-rifle.com/ivan-chesnokov.html
Terminals are great for CLI. CLI integrated into GUI/TUI is absolutely amazing, but 99% TUI apps do not work like that, they're just awkward crutches foreign to the terminal, so you get no upsides and all downsides. Examples of good CLI integration I regularly use: Kate, Zed, Dolphin, Total Commander, pi. Only one of them is TUI, and honestly it's much worse off with it, since it has to display a ton of formatted text and sometimes pictures. It's really inconvenient and just looks like cargo cult rather than a necessity.
But then a load of others will complain about electron apps.
Further you then have an os within an os. You need to remember to look in your bookmarks, not your start menu. And you're basically throwing away the window manager too.
I want to run web apps in my browser. I understand why Signal isn't a web app, and I'm willing to put up with that for security, but nobody else gets that excuse. Web apps belong in a browser tab.
The main thing I like is that TUIs are guaranteed to be navigable by keyboard. So many non-TUI apps don't include shortcuts at all for critical actions. It makes the first week of using the app more efficient and the entire rest of your life less so. Add on to that, I can probably run a TUI on my server. Or my cloud instance. And in my sandbox. Over SSH.
So: do make TUIs and bind their keys to Vi-like shortcuts as much as possible and I will use your app every time over a GUI app.
Pro tip for Mac users - install Karabiner and bind right-Alt + jklm to cursor movements. Immediate VIM navigation through the whole OS.
I don't disagree with you, but in ye old days you had guis that were navigable by keyboard.
And these were discoverable. That one program you use every day, you can spend the time to learn the short cuts. You can still get things done by clicking around though.
I suspect the underlying issue is one of limitations. Terminals are limited in what they can do. Guis and the web, you can do so much more, so people do.
I think another issue is touch screens. Guis and the web have moved to optimise for those. It decreases information density, forces a move away from the old standards to new much weaker ones. Tuis can't really do touch, so they don't have to make those tradeoffs.
The only one I use is Copilot (inside of a VM). ALl other applications I use are GUI/CLI/webapps.
Claude etc do make sense as TUIs too, but I don't like they way they were implemented. They mess with basic terminal features like copy/paste or scroll when there's no reason to. And they're somehow heavier than actual GUIs.
There are real advantages of TUIs: less CPU; sometimes I want to be using a personal TUI on a personal dev server quickly from a work laptop at lunchtime and an ssh + tmux + TUI is perfect; most modern TUI libraries are significantly less painful to work with than most modern web app frontend libraries; I can change the font size of my terminal easily if I need to, more easily than native (but not web app). But by far the biggest, is they just generally tend to be very fast and responsive compared to everything else.
While I get your point, a lot of vibe-coded agent TUIs (Claude Code, GitHub Copilot CLI, …) aren't exactly fast, either.
Sometimes I can use `du` to check what uses so much space, but sometimes ncdu is better for me.
And the best part - I can use both when I ssh to another machine, using the same command line, without thought. While GUIs need added thought, to switch from CLI to GUI on the remote one would need to use a different interface, or have X11 forwarding on (which is also a good option) and x11 libs on the other side.
Or use some other connectivity. ssh is simple, works on most servers I have access to.
Exactly. I'm currently on vacation and has checked in on long running Claude Code sessions over ssh every few days. I could have used X11 forwarding or VNC if I needed a GUI app, but the connection I'm on is currently slow and unstable, and using text mode has been far more palatable, especially since I can use tmux (or in the case of Claude Code, just using "claude agents" and let it background the sessions itself).
I'm currently trying to create a GUI version (immediate mode library) of a CLI tool of mine and it's mostly a shit show and three times the work of a data-in-data-out CLI tool. Good learning experience, though. I should note that I don't care whether the GUI version has a "native feel" or not (if you have the time to do so, be my guest), only whether it's functional and reasonably fast, since otherwise that's even more work for an open-source tool. Though, when I undoubtedly make the more interactive TUI version later on (ratatui just seems too nice not to try! :-)) it will probably bring a similar complexity development wise.
Then again I'm not into agentic coding at all so maybe the joke's on me. On the other hand, at the moment I need to learn about the data I'm processing, the GUI library/framework I use, and being able to help the people I work with troubleshoot the equipment that collects said data. I'd miss out on most of that if I coded by prompt. Perhaps I'll try later, perhaps not.
Keep making TUIs, or GUIs for that matter.
You can use them remotely over SSH connections, and they can survive disconects (within tmux). No VNC, or X11 forwarding needed.
They take less memory. compare vscode vs nvim.
Super fast to launch.
They can integrate with other TUIs and shell apps, shell-scripts, pipes
and lastly they do not contain Ads. lol
People are unable to do good GUIs. The web shows this; completely disregarding any UI guidelines by web people established since 80s is a proof that most people have no idea how to make GUIs.
I don't know how to make a good GUI. That's why I need good templates and strong guidelines, discipline and spend long time on design. Most people don't do that.
TUI is much, much easier. It's also possible to do bad TUIs, but it's easier to do a good TUI than to do an average GUI.
Intentional or not, the rhetorical style of the title, plus the subtitle opening on the word "weird" before it's defined, has an ostracizing effect on me. I guess that it could have an ostracizing effect on others, though I can only speak for myself.
GUI apps are only platform independent if you(r framework) make them so.
It's a quite common illusion that TUI apps are "automatically" platform independent. Even knowing which terminal emulator intercepts which shortcuts and how they handle width change, control character, mouse events, images, etc and design around them is not a trivial task.
On the other hand, making platform independent GUI apps haven't been easier. Just use Electron. Yes, performance blahblah, but thousands of Electron apps work on millions of machines just fine.
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 barely think about these things as “apps” (I have no intention to distribute them). They’re artifacts of me making my computer do stuff for me, the way I want it to. As a Unix nerd, I’ve always been able to do this, in the language of the command line. Now, it’s just as easy to do that kind of work with graphical interfaces.
And so the author (second sentence of the post)
> I built my first serious Mac application a few months ago, and since then I’ve built more native UI thingies than in my entire career prior to that.
I still build my personal stuff either for the command line (not even TUIs) or in a HTML page but I can see the point of creating a native app. Unfortunately there are some drawbacks: I would have to create the app for GNOME Debian and for Android, while a web app runs on both, and I would have to go all in on vibe coding because my last serious GUI programming has been in the 90s with Motif. The latter point is more or less the point of the author (the LLM does it for you) but it means that programming personal stuff will cost money paid to the LLMs companies. More and more money at each price hike and the multi thousand dollars box to run local models only makes the expense happen immediately instead of diluting over a long period.
Then why isn't it done more often? I suspect part of the reason is that most gui frameworks are not really designed for making dense economical interfaces.
> you probably don’t need a user interface on prod. You need a command line interface on prod that
I don't need one, but I often want one. Being able to run vim, htop, etc. on servers is quite useful. Also, it isn't just prod servers. It's also nice to run tuis on VMs and containers that don't have access to graphics.
> I’m not really building applications for other people to use. I’m building them for me. TUI affordances are an awfully big hit to take to get Linux users of programs I don’t even want to publish.
Ok. That's fine. But then why are you trying to convince other people not to make TUIs? If I make an app you find useful, wouldn't you prefer me to make a TUI you can run on your Mac to a linux-only GUI?
Because it tends to require a lot of thought and effort along totally separate engineering pathways than most of the actual functional coding. Good UI design is not easy, and the skills to do it don't directly overlap with good coding skills. It's hard.
> I suspect part of the reason is that most gui frameworks are not really designed for making dense economical interfaces.
Don't blame the tooling for a broad failing of many developers. It's because constructing a genuinely dense and economical interface for most apps requires considerable time and effort, and frankly, most developers are crap at understanding how users other than themselves use applications. Those that aren't crap at it tend to have worked in large teams with dedicated UX people to help drag them away from their preconceptions.
First, a TUI is usable with only the keyboard. Moving the mouse is a waste of time, and if you are using an application multiple hours a day, it can lead to being more productive.
Second, a TUI has no useless animations, elements, etc. It's not pretty, you have on the screen only the stuff you need to do your job, and you are not distracted by useless elements.
Third, a TUI works beautifully in a client/server world, where you have one central computer and dumb clients that connects to it, and the connection can be a simple serial connection as well as a network connection. It can be rendered even with an ESP32, making it suitable for embedded HMIs and all kind of computing scenarios.
Lastly, the user can choose the font, the colors, the size of the font that are best for him, usually a monospace font that it's surely better to read information multiple hours a day.
To me it's the opposite, GUI interfaces were born to make it intuitive to use a computer, but are not as efficient as TUI in terms of productivity.
Is it? Many TUIs these days don't allow me to configure my usual key bindings for moving my cursor within input fields. Meanwhile, GTK offers (used to offer) a way to customize key bindings across all GTK applications. (Unfortunately, they removed that feature in recent versions. Now I understand why people always get so upset about the GNOME devs…)
I've used the same systems you describe, except in gui form.
And the thing is, with this kind of application, everyone has a different 20% that they spend 80% of their time using. Guis can be as good as the TUI in the 80%, and very handy in the 20% where you aren't so well versed.
The issue, is that guis seem to have dropped the ball with regards to efficiency.
While I don't use most of them, but I can see why TUIs they are popular around devs. But in this post it reads like this:
"I don't like slop TUIs because they are popular, but please look at my vibe coded slop GUIs and I like vibe coding them and you should too"
One of the worst, if not part of my top ten worst blog posts I have ever seen on this orange site and absolutely do not listen to that horrible take that the author just wrote.
They don't support standard GUI shortcuts. They don't support drag-and-drop. I can't double-click a file and have it open in a TUI. They don't integrate with spotlight metadata. They don't ship document icons. They have terrible support for accessibility APIs. And so on...
Ctrl c does 2 completely different things. Terminology is different. Etc.
Problem is. Terminal applications standardised in the 70s. Guis in the 90s. Although that's being undone by web apps, and the influence of touch screens.
Put differently, a GUI application seems to subject you far more to the whims of Apple or Windows than a TUI and perhaps even a different run context. Maybe the permissions fiddling for this is insignificant. Is there a clear user contract from Apple or Microsoft about this?
Naturally, this is a non-issue in Linux.
I was alive back then already, and was a relief to finally be able to afford GUI powered computers.
Now everyone ships Electron crap, and then as alternative we are back into the 70's, because they cannot code anything else.
They're fast, efficient, work across SSH, in a tmux, and survive the almost daily browser upgrades.
And they are easy to run as separate users without VNC or sandbox hell.
Like do you want to think about X/Wayland isolation, or do you just want to get shit done?
The whole point of a TUI is that it can operate under no-GUI constraints.
I can SSH to any server and use a TUI because SSH can handle that. Running an entire GUI and setting up VNC/RDP would be horrendous by comparison.
Alternatively, a TUI can be a part of an interactive CLI command where it maintains context to your CLI session. For example, I have a tool that helps wrangle AWS accounts and regions where the CLI momentarily drops into a TUI to help pick between regions and accounts if not already specified in environment variables. If I had to type all that out every time it would be very annoying. Hitting some arrow keys or searching with a few letters beats the CLI experience, and a GUI experience is not possible.
> Meanwhile, if I build a TUI, I can be reasonably sure that Linux users are going to get the same experience I have. That’s not nothing. But remember: I’m not really building applications for other people to use. I’m building them for me. TUI affordances are an awfully big hit to take to get Linux users of programs I don’t even want to publish.
If we're just talking about personal or throw-away apps, yeah I'd probably just go native. But for things that I plan to use across platform, via remote shell, and for many years to come, TUIs has a huge advantage. I also think there's something powerful about the constraints of a terminal and the type of solutions it's led to. Constraints breed creativity, and in the case of terminals they also naturally steer towards high-performance, low-latency, and rapid interaction by experts. The fact that these things were born out of the limitations of early computing doesn't automatically make them outdated, to the contrary, it gives them staying power and portability.
In my mind there are crystal clear advantages to GUIs, TUIs, and raw CLI. I've used all of them extensively over the decades, and I've been impressed with the advancements in each over that entire time. I would never presume to tell somebody how to solve their own problems—if you're excited about something just go build it in whatever way makes sense to you.
- They encourage developing simpler, information-dense, and keyboard-driven interfaces, which I tend to prefer in general.
- I find them more fun to write, and less aggravating to maintain and debug, than interfaces built with GUI toolkits.
- Most software I write for personal use is going to be run in both a Linux and Mac OS environment (and a lot of the time on a headless server to boot), and a TUI often has less fuss than other options (at least, IME).
- I think monospaced text in a terminal just looks cool.
YMMV, of course, I'm just sharing my own experience and perspective.
Anything that lends itself to keyboard input, piping, text manipulation and a bunch of other things are so much faster if you're equally proficient in both input modes.
It is, of course, completely subjective, but I know there are a fair number of people out there who agree with that statement.
If there was a powerful, information dense, configurable docking/tiling, multi-application-composing GUI framework (all things a good terminal can do) then yes, build everything in that. I’d love to see it.
Until then, TUIs are vastly better than another Electron app or Mac app using UI frameworks that are trying their hardest to look and act like basic phone apps.
So even professional tools all follow industry design and product trends which are too simplistic, don’t give you the info you need, and are optimized for abstract brand design or chasing metrics for the company, and not optimized for “how do I let my user accomplish their task as fast as possible”
- keyboard can be used for pretty much everything
- less visually busy (no/less animations, background images/color variations. often close to plain text on plain background)
- more information dense (fewer things hidden behind hamburger menus, modals, drawers, etc)
- more/more easily customizable and documented
- more often can provide data directly into the terminal that I'm working in, so don't need to copy/paste through windows etc
these aren't necessarily impossible for GUI or universally true for TUI, but maybe I would guess just more an artifact of there being types of people who prefer working in the terminal who are then more likely to make TUIs, and I share their preferences more.
I love how I have to configure font size and family only once in the terminal emulator and not for each program/GUI toolkit again.
Of course, there is no way to replace graphical-heavy programs (GIMP, QGIS etc.) with TUIs.
<https://masysma.net/37/why_terminal.xhtml>
- Some are very good tools that have no clear GUI superiors. Vim, Emacs, Mc for example. GUI wrappers over these don't make them better.
- Efficient, meaning fast and limited in scope so you can learn the whole thing.
- The muscle memory you develop is transferable to any new platform or OS you use.
- Often free and OSS so they can't be taken away, making the muscle memory a long-term investment.
- If you work in the terminal for any other reason there's less context switch.
The low bandwidth / high latency lossy link problem is still a major issue. Cell phone service is sufficiently shitty in the area I live in that I have to use mosh to get a usable remote connection many times a year. Mosh is also quite useful while travelling! Got a crappy connection on a train or airplane? No problem. I have so much muscle memory with the mutt email client that nothing else has ever come close. Where's the equivalent of mutt's limit command in Thunderbird?
Try getting a usable VNC session when your cell phone hot spot is hitting 2-30 second ping times (yes -- thirty seconds) with only a handful of packets getting through.
Version 2 of the Amiga's operating system did a great thing in version 2 of AmigaOS which explicitly spelled out what conventions to apply (see Amiga User Interface Style Guide at https://archive.org/details/amiga-user-interface-style-guide). Modern GUIs that have weird meaningless buttons are infuriating. Even moreso when they lack obvious keyboard shortcuts.
I enjoy the usability and self perceived speed of not having to leave the console or reach the mouse to move a pointer when a cople of key presees is enough.
It's a matter of choice, I know, but I also think there is a genuine case for text over graphics. I see it everyday on businesses that keep old cobol tpvs at the cash, the speed at which the clercks check inventories or perform other crm activities is unmatched to mouse or touch interfaces
If you want to automate from the perspective of what's on screen, tuis have no metadata. A button in a gui does have metadata associated with it, so you could automate 'click button x' where as in a TUI you'd be limited to clicking 'position x,y'
For GUIs you have to handle the particular metadata of a given framework, if it exposes metadata at all for the controls. Otherwise you're dealing with raw pixels which is an instant nightmare, though not so much now there are visual LLMs, but you're still paying for the tokens and/or extra processing.
[0] https://gitlab.com/skeledrew/jaiver
- A lot of TUIs that run on your own machine and have a mature GUI alternative are indeed not necessary. I once tried to replace Spotify with ncspot, which was exactly falling into the "TUI is more advanced" trap.
- The real target of this article is people who treat TUI as a kind of identity, not people who have to work in a terminal because of their job and therefore have plenty of good reasons to use TUIs.
But the title and the general tone are still too clickbaity, which is kind of annoying. In reality, apart from a small portion of TUIs that were created just to follow the trend and clearly have better GUI alternatives, most TUIs are really just side tools that grow out of one premise that we have to work in the terminal.
And even those flashy TUI tools still make life easier for people who work in a terminal. If you prefer GUIs, fine, you don't have to use them, but that doesn't mean they have no users or no value.
That’s exactly what I thought too when I read the article. When the author mentioned the essay In the Beginning Was the Command Line I instantly knew it. I thought to myself the audience of the article must be the people who had read the essay and allowed it to influence their taste, as well as the people who might not have read the essay but conversed with people who did.
It seems like an absolute slam dunk for AI. Create an integrated AI screen reader app that observes the screen and talks to you. It wouldn't even need to be a huge model. It could be a small local model that can just read and interpret UI elements and feed the results as tool use calls into an accessibility layer. It'd probably be a custom trained accessibility model, could probably be based on an existing small computer use model fine tuned for the purpose.
This seems like the "accessibility solution to end all accessibility solutions" that totally takes the burden out of the code and puts it in one place that can be uniformly improved.
This is the way. It just wasn't possible 5 years ago.
One thing I think which is overlooked is the raw feeling of speed a good TUI can give you. The lowest grade consumer laptop could probably download my little dictionary program and still get true search-on-keystroke performance, because there is virtually nothing slowing down that path, no animations, no nothing. Now most of that comes down to the data structures involved and making sure nothing ever has to go over a network, but I still appreciate the sheer simplicity of the approach.
It's also nice to know that I can probably recompile this same exact code 50 years from now and still get it to run exactly as intended, since GUI frameworks have waxed and wanted in popularity, but terminals truly don't seem to be going anywhere.
Recently, I posted a GUI mp3 playing program written purely in Tcl/Tk using shell scripts for some things. On my 2011 desktop, filtering for a specific mp3 across all the mp3s stored on my computer (about 80GB of mp3s) takes single-digit milliseconds. I can only imagine what a modern desktop, with an SSD, will do!
GUI apps don't have to be laggy. My Qt and Lazarus apps aren't laggy at all, and are far more snappy and responsive than the clear majority of TUIs I use (like CC).
Now it’s “native apps for 5 platforms done almost for free” era for anyone who cares.
See Meta’s new AI desktop app (no, I won’t install anything from Zuck on my computer, but I appreciate what they did).
Can you elaborate?
The skills are useful, thanks for linking them! They'll be useful for my future projects like this. FWIW I've had good luck with using Claude Design first to do mocks.
At the same time, I think there's still the "is this worth doing a hyper-customized version of this software, if I'm also then responsible for fixing the bugs?". But I think increasingly as we improve our agentic workflows and make them more self-contained loops driving the result to completion, this becomes kind of a non-issue.
In general, I do think LLMs are bringing about a new age of hyper-customization, which I welcome.
You like GUIs and want to build/use ones that works in MacOS, that's perfect go ahead and build as much GUIs as you want. However, this wouldn't work for me as I know how bad developing native cross-platform GUI applications is.
People don't expect to be primarily typing into a GUI; they expect to occasionally click something interesting; have things pop into view as they happen, etc.
A TUI's advantage comes partly from imposing a constraint: how can we make close to all the user does in this thing and make it doable by typing at this cursor?
As always it's horses for courses.
1. CPU/memory performance on cheap or throwaway systems has a niche benefit. Mostly poor people. I'm still usually on an ancient Thinkpad with a 2nd gen i7. It runs native apps really fast to this day. Almost all GUI cuz I agree with the OP but my apps are TUI by default to keep them lean and fast.
2. Security. While I don't aim for it these days, it was much easier to make textual apps securely than GUI apps. Secure OS's from the 90's already secured console apps. TX, Nitpicker, and EROS made progress on GUI's but there's high complexity still. I'll note the OP's idea of GUI front ends is basically what we did to isolate the GUI part in a dedicated partition with messages it sends checked by the secure component.
Other than those observations, I'm with OP where I'm tired of TUI's if GUI's are that easy now. I considered trying it with some lightweight, cross-platform frameworks. Anybody tried some with cheap AI's?
You can also just use the system console with tmux or GNU screen if you absolutely don't want any graphics at all.
The TUI programs usually do not consume a lot of resources. They are also very fast and optimized for keyboard-only navigation.
[1] https://en.wikipedia.org/wiki/Text-based_web_browser [2] https://github.com/browsh-org/browsh
I understand the sentiment that TUIs is not as accessible, sucks to use. I still do not like the fact that we should "stop making TUIs" altogether.
Let me give you an example from my carpenter friend in Cananda. He has a saw (TUI) and electric one (GUI).
He uses the saw in diff ways than his electric one. He sometimes extend the saw by attaching it to end of a long stick to cut tree branches he cannot reach. He can do it with the eletric saw but requires much more effort.
But if he needs to cut down the tree, he uses the electric one, and sometimes finish off (trim) with the regular saw (so the tree falls in certain direction).
The gist is, TUIs can be used to do things quick and dirty, and easy/cheap to make/buy. GUI even with AIs, still not as cheap as TUIs to build.
TUIs has a different usage in our field, where it's used more for automation/piping. If you have GUI, it's hard to pull it off unless you build the functionality (which coulda been a command in TUI), and expose it via GUI. the Authros is focused more on consumer side than builder side. With AIs we will all be builders using AIs.
Lastly, shooting down people building TUIs is saying, no more innovations, by building upon other's TUI inspirations.
People write code using the platform X because they like it. It doesn't make sense to try to stop this
- I'm team GUI! The author outline elegantly why. Sometimes I put command-line-like things in the GUI; I generally view it as a superset of CLI, with vastly richer capabilities. This is kind of interesting in the bioinformatics/structural bio space, which I feel is inherently visual, and benefits from 2d layouts. Most of the tools are CLI and based in I/O of stdout and text-based files. I am taking a different direction!
> Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing industry on their shoulders. The Eloi use GUIs like Microsoft Word. Because this is high-test fan-service, “In The Beginning Was The Command Line” has become one of our field’s sacred texts, despite very little of it holding up 25 years later.
We should not take Sci-Fi and creative plot devices as predictions for the future. They can be inspirations and motivations for your own creativity, if tempered by realistic expectations and discipline. Neal Stephenson is especially prescient (Certain concepts from Fall; or Dodge in Hell and Anathem are hitting home strongly right now!). He spins vibrant, speculative yarns, mixing concepts, and estimating trajectories. The story referenced he is one that's in particular easy to see what parts did and didn't pan out. (And what Neal's more recent reflections on it say)
I think there is a bit of cultural identity (Which we are genetically inclined to insert in all sorts of places!) going on. There is a certain cyberpunk fun in SSHing a terminal, pipeling stdout/in together, and Viming. I suspect there is a high overlap between people for whom Linux is part of their identity, TUI use is as well. I.e, it's not about a practical weighing of merits; standard identity/tribal-based choices.
FOr use of TUI as a general file browser/command-executor... I've made my own. It's a GUI, and has built-in terminal for executing commands, with a visual file browser. And most importantly: Shortcuts to execute commonly-used workflows, history, bookmarks etc. All of which I feel like are glaring things missing from standard terminals. (PS, Bash etc). And having a terminal as one part of a multi-window program feels like a good use of my screen space!
Let people enjoy things.
My stances:
- Dev tools need a CLI at minimum, TUI for complexity
- User facing needs a GUI, CLI for power users
If you're building a TUI for a user facing thing, then yeah, you're doing it wrong, but if your target audience is devs then yes, PLEASE do a TUI, and make it nice.
EDIT
> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.
Oh, right. I can see that, but I go the other way: When I have a CLI, don't give me GUIs; give me files. Actually, just give me files and daemons. I'll do the rest, thank you!
I like chocolate I like vanilla
Its also a bit funny how the author show cases a bunch of apps that only exist on a very specific setup, IOS Mac devices while TUI can exist everywhere a terminal can reach.
The right tool for the right job, noone would srsly use a TUI photoeditor but for many things the simplicity and constraints that a terminal introduces condenses design.
I got this article about UI density open since weeks and meant to read it https://mattstromawn.com/writing/ui-density/ But from what I could interfere so far..more UI frameworks, more white space, more wasted space.
Also..TUIs usually allow me a wide variety of colorschemes out of the box which is nice
With X based apps, you can run GUI apps through SSH. That was all the rage for light remote access to resource hungry desktop app a few decades ago...
But that being said, in my opinion, a few limited TUI apps are useful, but most of them nowadays are young "cool kids" that wants to be cool by using "terminal apps" without really having really embraced the spirit of the terminal and commands.
For them, using GUI apps would look like a basic computer user and not an expert nerd.
The magic of the terminal, is not that you run things in almost black and white with low graphics, but that you were supposed to use "simple" commands that you can scripts and pipe one through each others at will.
Since I wrote my own terminal multiplexer that puts terminals on infinite zoomable canvas [0] and I just can't get enough of putting weird stuff like asciiquarium, cmatrix or tty-clock all around (tried peaclock but it's slightly too fiddly for my taste). There are fun projects just to run in TUIs like astroterm or weathr, but I'd say that the space is still open to terminal toys.
The only problem I have with TUIs is that they're boring after a while but something that can be solved with often theme switching.
[0]: https://race-term.com (commercial)
We run an internal agentic development harness we experimentally built for working on large-ish projects. first version started as a TUI, but it quickly became unusable for the large scale projects it was meant to work on (essentially PRD to PR, with planning loops, task decomposition loops and dependency aware execution / review loops). The TUI was too state-bound for another agent to drive reliably, and too cramped for a human to review at scale. We ended up replacing the TUI with a headless cli, and every interface we've built for the harness has become either a text artifact (mostly for agents to work) or a web view (for humans to drive and review).
UIs are also useful for information that is best represented in a UI. keep using those too.
You can bend each to be more similar to the other, and that's good too! Sometimes there is a good use case for that.
Well, that's a new one, ha ha (guessing "tripping balls" on GLP-1).
(And here I am too, about to be glipping balls… like everybody else, I suppose.)
On the other hand, they are easier to build in a cross platform manner.
Linux is probably the most difficult platform to build GUI for, because of all the fragmentation, X11, Wayland, all the different flavors of GUI toolkits, driver issues, window managers issues, font issues etc.
TUI are a bit like web apps in that regard, using the terminal instead of a browser to abstract the platform.
a lot of boomer and millennial dev users love TUI bc that's what they grew up with. part of A\'s early success is hit that sweet spot and triggered a culture shift late last year.
as those age group phasing out, web ui will be dominant
For something to become a GUI app (or a web-based UI) the GUI needs to offer something more valuable than a TUI can offer in terms of interaction.
I have one TUI app that wrote a while back to keep track of what I work on. It started off as a "wizard"-style UI. You choose project, then subproject, day, hours, activity and then hours and comment in a sequence of steps.
Arrow keys -> enter -> arrow keys -> enter .... -> comment -> enter
It takes about 2-3 seconds for me to do. And this is a time-sensitive task: if it isn't fast the user will not do it as often. There is a web interface to do the same thing, but the backend is slow. My TUI utility speeds that up by caching (between sessions) the things that the web UI has to look up (slowly) every time.
Then I wrote a more involved UI for it that "looks more like an application". Result? Now we were up to 15-20 seconds of interacting. Oh year it could do more and it certainly looked better, but it was less efficient so I noticed that I would postpone using it to record what I was doing. Because it now had friction. Lots of it. So a couple of weeks later I just did a hard reset and went back to the wizard style, minimalist version.
I would make a web UI, but that would burn 2-3 seconds just to navigate the browser there, juggle tabs (which I have too many of already), find the right browser to open the tab in etc. Once there do I keep it for "faster access" or close the tab? Keeping it is almost always the wrong thing.
There's a reason I have perhaps 15 different tools in my garage that can attach to a given fastener size. And there's a reason for that. Not all 19mm bolts are treated the same way. Some are low torque and live in tiny spaces. Some require precise fastening torque. Some need a lot of force to come loose - some will only come loose with force and I'm okay with destroying them. This is why I have so many tools that all do essentially the same job: apply rotational force to a piece of metal that has a standardized interface.
Similar tasks are not always best solved with the same tool because the context and the details do matter. Same goes for UIs. There are some things TUIs are very good at. Not least portability and remote usability.
I'll just copy a comment I made about this in another thread:
TUIs are just GUIs that use a grid of characters instead of pixels. They are strictly worse than true GUIs, by definition. The only thing I liked TUIs for is running over SSH, but can any of these newer ones really run over SSH with any kind of decent performance anyway?
I think people are confused and think they like TUIs because they like them being keyboard driven etc. But this could all be done with a GUI.
The other factor is probably just fashion. Similar to how some kids are now listening to music on cassette tapes, which are objectively worse than other media in almost all respects. The less cynical take is it's like vinyl: it does come with compromises but gives us back some of the things we lost over the years.
The actual interesting text-based interface is the CLI. I've seen a few examples of TUIs that really should be a CLI and would be much more useful as such.
There's more on this here: https://sockpuppet.org/blog/2026/05/12/emacsification/
I’m with Tom on a lot of what he says. This is a nice reminder to take another shot at this.
https://cushychicken.github.io/python-guis-for-heretics/
Terminal, coding, and even prompt writing skills are language skills.
If you cannot use a terminal properly you are basically an appliance user. Like a toaster operator.
TUIs are not for everyone by design.
maybe the answer is... you just don't need features like scrolling? this guy is trying to fit a square peg into a circle hole
Who said we're building them because we have to? I like TUIs, and often prefer them over GUIs, depending on the case.
https://github.com/tqbf/casette
It's inherently cross-platform (msys under windows). It allows to copy any part of UI. It doesn't require dependencies other than curses.
Like Brooke Shields, I'd rather nothing comes between me and my LLMs.
Back in the late 1980s, there was no question—the Mac changed everything, and everyone agreed that graphical was the superior interface. But we in the Unix world were slow to convert fully, because of a couple of problems:
* designing GUIs is hard, especially for programmers;
* writing GUI code is hard (and often tedious).
So good GUI apps really came from teams of elite designers and developers. The best ones all worked for Apple. There was an acceptable second tier that all came from major companies. If you wanted to write a custom one-off tool for yourself, however, you'd be in for some pain and the result would be jank.
But LLMs solve both problems. Point Claude at a description and some mockups of an app, and it will give you that app, or at least a slick-looking prototype that is suitable for your use if not the wider market's. So we no longer have an excuse. ALL our apps should be graphical, because creating graphical apps is now easy.
No, they didn't. The Mac's GUI benefitted in certain specific applications, like DTP, early on, but the Mac was an also-ran for most serious productive work for a very long time, and even when GUIs became standard in the PC ecosystem, it wasn't until the late '90s that productivity apps decisively moved from the DOS-based TUI world to Windows GUI applications.
> So good GUI apps really came from teams of elite designers and developers. The best ones all worked for Apple.
The folks who actually managed to build interface paradigms that successfully reconciled complex business functionality with sufficiently easy-to-master GUIs worked mainly for IBM and Microsoft. The CUA paradigm was the winner here.
People seem to forget that Apple had next to zero penetration into the business computing market, and nearly went bankrupt, back in the '90s.
As in, using graphics, vectors, but with a fully text-based UI?
Also the original Metro design as in WP 7/8/8.1 or Windows 8/8.1 relied heavily on the pure text, and the only place populated with a lot of icons was that iconic tiled start screen, although this is probably not what you mean.
Sure it looks pretty but it’s impossible to drive from the keyboard without mutant hands and savant level of memory for arcade combos. That means the entire OS relies on being able to drive the UI from a positioning device and thus you have to have the coordination to piss on an ant off a moving train. Which is terrible when the input devices are a touchpad, which varies so utterly frustratingly depending on whether it’s in the laptop or over Bluetooth. That and a mouse which is designed by a complete psychopath. That leaves you with third party options which require apps to not suck and they still suck. Scrolling on Logitech options anyone? Even LinearMouse can’t fix that shit.
Compare windows which works absolutely fine from any keyboard or any mouse and is discoverable and consistent. Also no mutant hands required.
TUIs are closer to windows than macOS. And that’s a good thing.
I did the last ten years on a mac and decided I was just hurting myself. Give me windows or a TUI. I notice Linux desktop environments tend to copy windows with respect to keyboard and discoverability too.
There's a shorthand that derives from the Phoenician string instrument : nabla . Latex has it as \nabla
You want it graphical: Make a webapp.
You don't: Make a TUI.
What exactly is the use case for native apps? Even lots of legacy code can build to WASM now.
(yes, I'm exaggerating a bit, but not much)
I'd take TUI apps over electron apps everytime as long as the UX is good.
Nowadays, you are more likely going to struggle with plugging your laptop into a 320Volt outlet than have a terminfo problem.
TUIs are a creative constraint.
TUIs are an invitation for programmers.
TUIs are doing "less" to render.
TUIs don't need to be "responsive".
Hello World is TUI.
Easier to test too. Try testing your beautiful claude design React app end to end
Making GUI apps has been way too hard on all platforms since forever. Frankly I think it's gotten worse for 20 years. People started fleeing to web wrappers like Electron to escape the horrors of native UI development.
So if that was the reason why you made a TUI, take heed. LLM's can chew through UI frameworks for you.
But I solidly believe TUIs are often better than GUIs even if they were equally easy to make. They liberate your app from having to follow the fracture and fashions of GUI's - Liquid glass, Windows 8, SwiftUI, WinUI3, QT, GTK or whatever. A TUI allows muscle memory that you learned on Solaris in the 90s to work fine in windows 11 in 2026.
What the what now?
The author starts with a bunch of vibecoded slop apps that show exactly what I hate about 'modern' GUI apps, a lack of options and wasted screen-space. They look hip but are harder to use to me.
You are free to build anything you like, and whatever you build won't affect me at all.
>[...]
>But remember: I’m not really building applications for other people to use. I’m building them for me.
Giant caveat to the whole argument and it's buried 80% of the way down. Granted, he alludes to that a little earlier, but if other people using your application are a completely irrelevant outcome, you're an unusual case.
I mean, sure, I make tiny one-offs, but those barely even have something you could call a CLI. I push as much complexity into command-line options and config files as possible.
And now libghostty has caught up with a full implementation of the protocol in a second terminal emulator. I guess that mitchellh has plans for use in Superlogical... https://hachyderm.io/@mitchellh/117135178412268410
It’s much easier for the clanker to loop on testing / improving the TUI than a real GUI. It also means it can work on the app without an API/REST/HTTP/Java/Script ball of mud in the middle.
Does anyone else find that this reflects a really obnoxious attitude, regardless of whether it would work?
Anyway, it seems like the premise is that people would only ever build a TUI because making a GUI was hard, and now it isn't because LLM slop will be good enough. But I'm firmly convinced that fails on both counts.
The primary value statement of TUIs is that they work over SSH with remote systems.
But now, we're hearing rumbles about the limitations of the "modern" terminals with regards to working well with a "rich" TUI. How a raw tty doesn't really cut it since it, at a minimum, can't detect key presses, only actual character/byte patterns. How there needs to be a new protocol, a "better" terminal client.
Of course when you go that route, then the current terminal emulators will need to be updated, or you'll be required to install a different terminal emulator that supports the new protocol. But that kind of defeats the theoretical, historical ubiquity of a TUI. It would not surprise me that many modern TUIs only work with an ANSI terminal.
Back in the day, we had systems like Visual Basic, Power Builder, SQLWindows. GUI/language systems particularly well suited for Client/Server DB development.
For a time, Firefox actually presented itself as a modern incarnation of these tools. Using XUL and JS for UI development, built in utilities to talk back to servers over HTTP. It was a platform for "Rich Internet Applications(tm)".
It didn't really take off, it wasn't documented very well, kind of buggy. It also required Firefox as a client. The potential was there, but not quite realized. Ajax hit the web browser in full force and that pretty much was the last nail. Now, you could use "any" browser for more interactive applications.
Of course, we advance to today, where many sites work in any browser as long as its Chrome. We have advanced applications that are no more than a Canvas element, with everything else being reinvented from scratch. "Have bitblt, will travel."
The browser is the closest thing we have to a universal remote GUI, but we all know the issues with it for many contexts. As an application platform, it may be ubiquitous, but that doesn't mean it's at all lightweight.
We used to have lightweight, remote GUI applications. Rootless X Window applications. Folk don't necessarily want the entire desktop, they just want an app, with some fields and buttons. You could slap them together with TCL/TK. Remember dtksh? We're not talking about trying to write Adobe Premiere or AutoCAD in these things. We just want some simple utilities, fields, icons, maybe a chart. Scrolling tables and a menu.
But we can't do that today, not readily, not easily.
So, we're kicked back to 1978 and the rise of the Smart Terminal, instead of 1984 and the rise of the X Terminal.
If folks are going to write out a custom client for a TUI, then may as well go the extra 10 feet and make it a remote GUI client. Reinvent all of the wheels as they go round, and round again.
[1]: https://en.wikipedia.org/wiki/WIMP_(computing)
TUIs, at least to me and some friends in my circles, do something that native applications don’t: demand focus from the user.
Sure, modern terminals and TTY environments have visual tabs and virtual terminals that let you quickly toggle between multiple apps, and you can of course manually code your screen to split apps across a single “window” if you really want to get into the guts of things.
But for several folks in my close circles (myself included), the fact that each TUI occupies an entire screen by default, forces us to focus on what’s going on and what tasks we’re trying to accomplish in a way native UIs don’t. On the desktop I can flit between Discord and Telegram and multiple games and several Firefox windows full of tabs and the video encode I’m working on and hey did that bank transaction go through let’s check my email except UGH music streaming went off the rails so let me go back to my client and-
You get the idea. For folks who lack the neurotransmitters to maintain consistent focus or wave off distractions, a terminal environment acts as an accessibility device in and of itself. btop on 1, irssi on 2, Hermes (Qwen 35B) on 3, with 4 as my primary workspace and 5 as a fallback. Simple. Clean. Efficient. Lightweight.
I generally concur with the author that we should be “summoning” (I love that word for reasons that deserve their own essay/comment) more native UI apps that are as information-dense as, well, Bloomberg Terminal. There’s no reason we can’t build something as powerful and focused for the everyman for, say, inventory collections, or K8s constructs, or network architecture, all in a native UI. There’s nothing wrong with the GUI, only that at some point we let ourselves get suckered for the narrative that GUIs have to be easy, simple, and opaque, as opposed to transparent and (logically) complex. We can and should build GUIs that flow logically like the commands they’re executing behind the scenes; hell, we should be able to open a console log of every action we took in the GUI and the associated command(s) it executed, so we can better learn to transpose from GUI to CLI ourselves and build more capable or complex automations.
GUI isn’t bad. TUI isn’t bad. What’s bad is presuming one or the other is superior to everything (or for everyone) else, or worse, assuming one cannot function in a given way comparable or equivalent to the other.
Lists a bunch of things .
Fails to make any clear points .
Fails to give real reasons for the few claims it makes .
- All those GUI windows look the same. How the fuck do I tell one app from the other?
- The abysmal corner radii are a clear indication of terminal macOS. Pun fully intended.
I can see how LLMs help.
I wouldn't want to maintain software for other people entirely vibe coded. I think I might think again about native app development for my own needs, if it's kind of disposable.
People talk shit about LLM writing. Well, here's a prime example of why I like LLM-speak. Does this article have personality? Yes. Attitude? Yes. Is it structured and accessible? No.
I'll take clarity over personality any day of the week.
Of course, I didn't mean to imply that there's a dichotomy between personality and clarity. There's a dichotomy between ordinary LLM writing and personality.
Here's an organically grown summary:
• TUIs suck because they are primitive, often buggy, hard to write and aren't accessible. Their existence isn't due to any real technical advantage but more because UNIX historically had a very bad UI toolkit (Motif) which established a 'culture' of TUIs.
• It's now easy (on macOS) to write native apps that use SwiftUI and give a much better GUI. You can just vibe code them.
• Some specific skills, features, templates etc are linked which look useful if you agree with this approach.
• You don't have to give up remote access because there's no reason the GUI has to run on the same machine as the thing it controls. A native GUI can just SSH in to a remote machine and run non-TUI CLI tools to control it. Lots of apps have worked this way and it functions fine.
• On the other hand, TUIs are portable (ish). The author concedes this may sometimes be useful.
I prefer my articles to be coherent without having to wade through pages worth of irrelevant material.
i.e. ignorance is bliss in the world of typography.
The total abandonment of the form-follows-function principle on the part of purely visual designers, who worry about what software looks like without considering what it's for, has led to 10-15 years of cumulative usability degradation in almost all categories of software. TUI and CLI software remains one of the last bastions of people actually designing interfaces for functionality and usability.
Just because there have been some crappy industry trends doesn't mean the answer is to turn away and permanently regress to the confines of a terminal emulator.
Sure I can. That's not to say that it's completely useless and not worthy of any attention at all, just that it is far removed from the primary considerations of software design -- it absolutely is an aesthetic matter that is not an important consideration until functional design is settled.
And sure, for programs for one go ham on the ui.
No, for the love of god never stop making TUI's.
Who tf cares about what the author who appears to be new to building native desktop apps (and vibe codes them) says about terminal apps?
I am not writing my code 3 times for each native platform even for agents and then dealing with signing keys just for it to break on a OS update. Terminal apps for developers survive all of this.
The entire article is just a massive rant with woefully weak points. I guess agents really does amplifies both Gell-Mann Amnesia and Dunning-Kruger in others.
So one reason to write this post is just to send a bulletin to developers like me, for whom it wouldn't have even occurred to build native UI before. Native UI is now a thoroughly solved problem. All "off the rack" user interface is solved now.
But that's not the biggest thing happening here.
What's really going to destabilize us is what this says about computer usage and computer programming. When I was a little kid, in the mid-1980s, I imagined all sorts of new different things I could do with a computer, if we ever got one besides the ZX81 clone that plugged into our TV.
I had to grow up to become a computer programmer to learn that one doesn't simply tell a computer to do new things, that there's an elaborate ritual to build anything useful, and it takes years to get comfortable with those rituals. And like most other programmers, and really craftspeople of all stripes, I came to appreciate the rituals and the specialized knowledge. They're part of my identity, so I tend not to question them.
But there's always been this dividing line between computer users and computer programmers. It's rarely disrupted. It happened once with spreadsheets (our profession has a sort of Kubler-Ross thing going on with the fact that Excel formulae are the world's most important programming language), and maybe just a little bit with HTML in the early web. Other than that, we've all been pretty siloed.
That's obviously about to change, in a more significant way than it ever has before. Computers are going to work the way I assumed they did when I was 7. The line between programmer and power user is going to dissolve.
I'm not interested in what that does to our profession or the question of whether or not there will always be a need for serious software craft or engineering or whatnot. Totally valid question, but not where I'm coming from.
I'm interested in what systems look like in this new world we're heading into. What is an operating system in a world where most applications are summoned by the person who's going to use them? What even is an application at that point? What are the interface idioms when we're truly no longer constrained by text inputs to compilers and program building tools? Does everything look more like Smalltalk? Like a Lisp Machine? Or like something weirder? It's gotta be something. It can't possibly be the case that the shape of computing we all count on today is going to survive the next 15 years; it'd be like driving steam-powered automobiles.
That's the fun question.
> Our field has a weird relationship with terminal and command line interfaces. The time has come to re-evaluate it.
Why? Why is infatuation weird? Why should we reevaluate it? The whole premise sounds like a "give me a hot take on XYZ".
(I built itter.sh so I'm biased)
/s
AI slop spam.
I don't want to use those AI sloppers. They often are not based on any intelligent design.
A good counter example is, in my opinion, htop. Many people use it, despite its ncurses-nature. It simply does what it wants to do well: give an overview over resource usage.
Yes, AI slop can spam-generate a clone, but why would I want to use that over the real thing? It makes no sense.
> I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful.
I don't want this spam slop anyway, but notice that the author became super-lazy. Rather than providing source code, he tells you to copy/clone it via Claude spam. So this human is now too lazy to do anything useful. Skynet won. He has been AI slop spam absorbed, without even noticing. Just like in the movie Invasion of the body snatcher (great movie, both the original and the first remake, though I liked the remake more, because Sutherland was in his prime back then).
The author continues to show more AI slop spam created useless things. None of which is interesting. I am surprised people now blog about boring AI created software and call it engineering. So, nah, don't stop making TUIs. Instead, design them better.
Having said that, I think ncurses is the wrong tool in general. We need to be able to design both TUIs and GUIs in one go without barriers. Every time I have to use ncurses, I do indeed curse.
and it "worked" - the audience he found for this is bigger than the previous one. So this continues until the AI psychosis become so high it start to turn people off.