alt Hacker NewsStop Making TUIs
Comments
Funnily enough I wrote a similar blog about this in the era preceding LLM assistance.
I’m with Tom on a lot of what he says. This is a nice reminder to take another shot at this.
"Q: Son, what is window manager needed for? A: Running multiple terminals on one display."
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.
It’s a matter of preference: Everything OP says about GUI development getting easier is also true about TUI development getting easier.
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!
> 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
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.
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.
[0]: https://race-term.com (commercial)
Stop telling people what to do :/
Let people enjoy things.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Text-based_web_browser [2] https://github.com/browsh-org/browsh
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.
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.....
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.
The article is interesting even if you disagree with the headline conclusion -- don't skip it on that basis.
TUIs are just an accessibility nightmare without any of the advantages of a CLI like scriptability. Truly, Truly horrible
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.
Stop telling people what to do (or not).
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
"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.)
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).
> 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
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
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.
Sometimes I wonder if people are just writing these for the sake of having written something.
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.
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.
I think I'll keep making TUIs but thanks.
Easier to test too. Try testing your beautiful claude design React app end to end
But TUIs make me feel smart, and my work feel important and esoteric.
From tui i can copy (all) text and run it over ssh, only a good image protocol is missing for me
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.
> 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
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.
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.
>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.
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.
TUIs are good for users, because they don't require using mouse as much - I didn't see this argument covered.
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.
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.
I wonder if devs are flocking to TUIs to gatekeep against normies building apps
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
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.
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.
TUIs allow you to have infinitely many running in tmux and also work over ssh so there is that.
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.
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.
>> Because I assume that agents work better with a filesystem to grovel
What the what now?
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.