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.
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.
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.
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.
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.
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.
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.
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.
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
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...
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.
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.
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.
- 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.
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.
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?
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.
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.
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
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.
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.
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?
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.
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.
[1] https://github.com/charmbracelet/bubbletea
[2] https://github.com/charmbracelet/wish
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.
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 macOS AppKit, GTK, Qt, WinUI, Electron where you'd have to decide to support multiple windows.
Why? Because just look at the examples on that page.
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.
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 salute you, heros.
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.
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...
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.
- 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.
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.
- 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.
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 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.
Once we have robust automated computer use, that becomes the verification loop, and this problem will almost surely get solved.
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'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?
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.
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.