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.
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.
> 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?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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!
The typical TUI fan is a nerd with no clue about typography so therefore they don't have any problem with being shown stuff that has no reason to be monospaced in monospace. i.e. ignorance is bliss in the world of typography.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
>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.
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.
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.
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?
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.
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.
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.
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.
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.
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”
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.
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
- 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 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
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'
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.
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.
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…)
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.
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.
> 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).
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.
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.
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.
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...
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.
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).
> 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.
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 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!".
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
Let people enjoy things.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
But I don't think I've run into a TUI that I couldn't have multiple instances of.
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.
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.
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.
It's inherently cross-platform (msys under windows). It allows to copy any part of UI. It doesn't require dependencies other than curses.
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.
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, 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
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.
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.
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.
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.
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
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.
The same reason webui and js is so popular!
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.
Once we have robust automated computer use, that becomes the verification loop, and this problem will almost surely get solved.
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.
I salute you, heros.
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.
> 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.
- 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.
It is, of course, completely subjective, but I know there are a fair number of people out there who agree with that statement.
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.
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 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
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.
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).
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.
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
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.)
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.
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.
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
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.
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).
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
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.
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?
People write code using the platform X because they like it. It doesn't make sense to try to stop this
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.
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.
No, for the love of god never stop making TUI's.
Lists a bunch of things .
Fails to make any clear points .
Fails to give real reasons for the few claims it makes .
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.
- 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.
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.
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.
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.
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)
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.