Stop Making TUIs

> 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

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.

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.

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.

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.

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.

Stop telling people what to do :/

Let people enjoy things.

The nice thing about TUIs is: they are platform independent. Whereas with SwiftUI apps you are bound to macOS.

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.

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!

Counterpoint: Build more TUIs in Rust using Ratatui: https://ratatui.rs/

Why? Because just look at the examples on that page.

"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.

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.

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.

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.

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.

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.

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.

"Q: Son, what is window manager needed for? A: Running multiple terminals on one display."

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.

I'm currently building a winamp clone that works over ssh, using textual. So I'll have to hard disagree

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.

No. I like them.

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.

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.

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.

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.

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.

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

"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.)

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.

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

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...

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).

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.

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.

> 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

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.

Or, perhaps, stop making pomodoro apps, todo list apps with budgeting as their 'unique' killer feature, and damned Markdown viewers. Seriously.

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

You can't ssh into a swift app.

TUIs are just an accessibility nightmare without any of the advantages of a CLI like scriptability. Truly, Truly horrible

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.

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?

No.

aerc is the best program I've ever used. tmux from anywhere. May TUIs never die.

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

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.

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.

Or, you know what, don't listen to strangers on internet telling you what you should do. Do what you want.

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.

No.

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.

This piece is just marketing for all the authors slop coded projects

I feel like this is the typical MacOS user stereotype.. Cosmetics over efficiency.

No, for the love of god never stop making TUI's.

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.

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 .

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)

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.

Do more TUIs. Please.

"Stop liking things I don't like!!"