121–130 of 579 posts
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.
You know what's awesome about TUIs? They live in a tab in my terminal. 95% of the time, my system has three windows open: terminal, browser, Signal. Please, make more TUIs and web apps, so they can live in my terminal or my browser.
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…
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.
Earlier quoted context omitted.
But in the article all these GUIs are vibe coded. Tell your AI to allow more than one window. What's the problem?
Then you'd have to contend with the rest of the list of TUI advantages over GUIs, like trivially operating them as they run on remote machines.
Earlier quoted context omitted.
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 h…
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.
YMMV, of course, I'm just sharing my own experience and perspective.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
Then you'd have to contend with the rest of the list of TUI advantages over GUIs, like trivially operating them as they run on remote machines.
That is, as TFA mentions, the one good argument.
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.
Earlier quoted context omitted.
Huh? None of these force single-instance by default
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.
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.
Earlier quoted context omitted.
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.
Your argument in favour of TUIs is that they can be, in fact, not TUIs and actually CLIs
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. Seco…
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…)
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…
While I get your point, a lot of vibe-coded agent TUIs (Claude Code, GitHub Copilot CLI, …) aren't exactly fast, either.