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.
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?
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.
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.
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.
I like browser-based UI, as they offer similar advantages to TUIs: You can use the UI on a different machine than the application itself is running. Arguably, modern Web standards also lend themselves to some elegant code design for UI. However, the "waste" is a valid point, but then again your TUI (and many GUIs) will fail on those things that cause the "bloat" of a browser: support for the weirdest encodings, dealing with the most absurd edge cases, supporting the largest amount of devices in a uniform manner. Shipping a whole electron for your crappy app is not what I mean. This should stop, as it trades all advantages for almost only disadvantages.
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.
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.
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.
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.
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.
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.
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 way 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 way larger input space than a mouse, and if I can keep both my hands on the keyboard, I can work much 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.
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.
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.
If that's the only justification, a good window manager might turn out a lot more convenient.
Terminals are great for CLI. Terminals that integrate CLI and GUI/TUI app's internal state are absolutely amazing, but most TUI/GUI apps do not work like that, they just awkward apps 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.
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
Hot take: Too many people are building UIs 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.
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?
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.
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?
My guess is that is because a TUI can’t give focus to the existing instance. When a GUI application realizes that an instance is already running, it can ask the windowing manager to unhide and focus the running instance.
For a TUI to do the same, it wouldn’t just need to find and focus the window, but would need to trace it through the myriad ways that a TUI can be displayed. I may run a TUI inside a docker container, as part of a tmux session, over ssh. If a TUI somehow managed to focus the existing instance through those layers of wrapping, I would be very surprised, disgusted, and impressed.
So I think it’s that the end goal of “redirect user to existing instance” is infeasible, so nobody bothers to enforce a single instance, since the rest of the steps aren’t possible.
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.
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.
That’s interesting. The browser is also a host of multi-instance applications which makes it a good platform for this. The ChatGPT web app works better with multiple tabs than selecting its in-app sessions in a single tab. Good observation.
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.
Heh, I have one in C23 with Ruby, Python, Go, and JS bindings...may have gone overboard. Not going to publish though until I have dogfooded it enough though :P
Please, don't. One of the main benefits of TUI is being able to freely copy text, I hate opening Textual application and being dropped into this canvas like state.
Looked and see all the same awfulness expected of a textual interfaces where drawing a vertical line is not trivial, so many have gaps instead because they don't know they need a different character
Or where the gaps between elements is huge because your min width is bounded by a char.
Etc.
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.
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 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.
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.
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.
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?
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.
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
492 comments
[ 254 ms ] story [ 486 ms ] threadApple 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.
The same reason webui and js is so popular!
No they don't. Many components are SwiftUI only.
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.
People talk shit about LLM writing. Well, here's a prime example of why I like LLM-speak. Does this article have personality? Yes. Attitude? Yes. Is it structured and accessible? No.
I'll take clarity over personality any day of the week.
Of course, I didn't mean to imply that there's a dichotomy between personality and clarity. There's a dichotomy between ordinary LLM writing and personality.
Here's an organically grown summary:
• TUIs suck because they are primitive, often buggy, hard to write and aren't accessible. Their existence isn't due to any real technical advantage but more because UNIX historically had a very bad UI toolkit (Motif) which established a 'culture' of TUIs.
• It's now easy (on macOS) to write native apps that use SwiftUI and give a much better GUI. You can just vibe code them.
• Some specific skills, features, templates etc are linked which look useful if you agree with this approach.
• You don't have to give up remote access because there's no reason the GUI has to run on the same machine as the thing it controls. A native GUI can just SSH in to a remote machine and run non-TUI CLI tools to control it. Lots of apps have worked this way and it functions fine.
• On the other hand, TUIs are portable (ish). The author concedes this may sometimes be useful.
I prefer my articles to be coherent without having to wade through pages worth of irrelevant material.
- 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.
People write code using the platform X because they like it. It doesn't make sense to try to stop this
Please, make more TUIs and web apps, so they can live in my terminal or my browser.
[1] https://github.com/charmbracelet/bubbletea
[2] https://github.com/charmbracelet/wish
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.
While a mouse can theoretically use all pixels of a screen, in practical terms a keyboard has a way larger input space than a mouse, and if I can keep both my hands on the keyboard, I can work much 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 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.
Native UIs simply don't have the same flexibility.
Terminals are great for CLI. Terminals that integrate CLI and GUI/TUI app's internal state are absolutely amazing, but most TUI/GUI apps do not work like that, they just awkward apps 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.
So you can't even immediately switch to your app and don't see it in an OS-integrated list?
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
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.
Meanwhile a GUI's developer has to decide to grace me with the ability to even open more than one window.
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.
They are usually tied to specific user accounts, it's true. But that's something some people made up, and it doesn't have to be that way.
But I don't think I've run into a TUI that I couldn't have multiple instances of.
For a TUI to do the same, it wouldn’t just need to find and focus the window, but would need to trace it through the myriad ways that a TUI can be displayed. I may run a TUI inside a docker container, as part of a tmux session, over ssh. If a TUI somehow managed to focus the existing instance through those layers of wrapping, I would be very surprised, disgusted, and impressed.
So I think it’s that the end goal of “redirect user to existing instance” is infeasible, so nobody bothers to enforce a single instance, since the rest of the steps aren’t possible.
Emacs Server and tmux would both like a word. Make the current tty show the app output.
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.
Pretty much all GUI frameworks I have worked with behave the same, and you have to actively create singleton behavior.
Then you have Mac OS which makes it hard two create multiple processes of a GUI app. Other OSs don't necessarily behave the same.
https://en.wikipedia.org/wiki/Tab_(interface)
Same with docker containers
Same with concurrency
Same with exec
Same with bsd jails
Same with copies of data in a for loop
Same with recursive functions
Same with numerous copies of image viewers showing the same jpg and txt files
...it's all arbitrary containers and arbitrary recipes to encode and decode binary
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.
Why? Because just look at the examples on that page.
Or for Go coders there's BubbleTea: https://github.com/charmbracelet/bubbletea
Why? Because TUI!
Please, don't. One of the main benefits of TUI is being able to freely copy text, I hate opening Textual application and being dropped into this canvas like state.
I guess it’s a matter of taste ¯\＿(ツ)＿/¯
I love the visual style. It's especially interesting to set the colour scheme to the orange/yellow glow of reaaaly old school terminals.
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.
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.
A good engineer has the ability to pick the right tool for the job based on matching said merit profiles to the problem space.
A mid engineer just does the thing that is currently cool without spending much thought on the why.
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.
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?
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.