I love a GUI in many cases! But if I'm building something, I personally want it across Linux and MacOS at least (personal and work, respectively). TUI answers that problem quickly, easily, effectively, and efficiently.
I'm actually amazed that we have never gotten to a really good UI framework that is cross platform. I really just want something like SwiftUI that's truly cross platform, personally. There are a million arguments to say that we do have cross platform GUIs, but all of them lack in some major way.
One example - wxWidgets exist, and wxDart exist, but getting to something half as usable as Flutter from there is almost impossible. I defy you to even build a layout engine that works on all three platforms. After that, you still have to find answers for theming, spacing, responsive behavior, component composition, inspection/debugging, hot reload, accessibility conventions and on and on.
Just curious re: the obvious example of "The Web" - do you consider it "not good" or "not really a cross-platform UI framework" as such?
It's also generally resource intensive, compared to a solid native UI.
I would say that, if you don't need more native control, the web is the best cross platform interface we have, by far. But not having those system API really starts to limit it for certain tasks IMO.
When I just want a graphical utility, I build a single HTML file that includes all of the assets required, and all of the JavaScript so I can run it offline (but generally host them on my site so I can get to them from anywhere). These tools are generally text in and text out that I want a GUI representation for and don't need in the terminal.
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.
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.
It's not true for AppKit, SwiftUI, GTK, Qt, WinUI, or Electron, and I'm not sure what's left.
It looks like macOS Finder tries to make it difficult to run two copies of a .app simultaneously, so I imagine many programs don't check for this case, but this is Hacker News, so we can use our hacker skills to try and do what they don't want us to: find the exe inside the bundle and run it directly from Finder, or run it from the terminal using its path. (This works for me with Ptacek's mdv app. Two copies of it end up in the dock.)
https://www.electronjs.org/docs/latest/api/app#apprequestsin...
and handle this event:
https://www.electronjs.org/docs/latest/api/app#event-second-...
I believe macos is the only OS that enforces single instance by default. If you start xterm five times on linux, you get five independent xterm processes.
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.
Just like you can start vim several times you can start gvim several times and have a few windows. This is the default behavior, and if the developer wants to change this for some reason, they need to put in some effort.
Maybe macOS is special? I'm not familiar with this platform.
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.
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.
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.
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.
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.
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.
The primary value statement of TUIs is that they work over SSH with remote systems.
But now, we're hearing rumbles about the limitations of the "modern" terminals with regards to working well with a "rich" TUI. How a raw tty doesn't really cut it since it, at a minimum, can't detect key presses, only actual character/byte patterns. How there needs to be a new protocol, a "better" terminal client.
Of course when you go that route, then the current terminal emulators will need to be updated, or you'll be required to install a different terminal emulator that supports the new protocol. But that kind of defeats the theoretical, historical ubiquity of a TUI. It would not surprise me that many modern TUIs only work with an ANSI terminal.
Back in the day, we had systems like Visual Basic, Power Builder, SQLWindows. GUI/language systems particularly well suited for Client/Server DB development.
For a time, Firefox actually presented itself as a modern incarnation of these tools. Using XUL and JS for UI development, built in utilities to talk back to servers over HTTP. It was a platform for "Rich Internet Applications(tm)".
It didn't really take off, it wasn't documented very well, kind of buggy. It also required Firefox as a client. The potential was there, but not quite realized. Ajax hit the web browser in full force and that pretty much was the last nail. Now, you could use "any" browser for more interactive applications.
Of course, we advance to today, where many sites work in any browser as long as its Chrome. We have advanced applications that are no more than a Canvas element, with everything else being reinvented from scratch. "Have bitblt, will travel."
The browser is the closest thing we have to a universal remote GUI, but we all know the issues with it for many contexts. As an application platform, it may be ubiquitous, but that doesn't mean it's at all lightweight.
We used to have lightweight, remote GUI applications. Rootless X Window applications. Folk don't necessarily want the entire desktop, they just want an app, with some fields and buttons. You could slap them together with TCL/TK. Remember dtksh? We're not talking about trying to write Adobe Premiere or AutoCAD in these things. We just want some simple utilities, fields, icons, maybe a chart. Scrolling tables and a menu.
But we can't do that today, not readily, not easily.
So, we're kicked back to 1978 and the rise of the Smart Terminal, instead of 1984 and the rise of the X Terminal.
If folks are going to write out a custom client for a TUI, then may as well go the extra 10 feet and make it a remote GUI client. Reinvent all of the wheels as they go round, and round again.
You can use them remotely over SSH connections, and they can survive disconects (within tmux). No VNC, or X11 forwarding needed.
They take less memory. compare vscode vs nvim.
Super fast to launch.
They can integrate with other TUIs and shell apps, shell-scripts, pipes
and lastly they do not contain Ads. lol
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.
Good luck exhausting Claude. As long as you keep feeding in quarters, it will keep hacking Qt.
I’m with Tom on a lot of what he says. This is a nice reminder to take another shot at this.
This pretense that the entire value of source code is the "spec" / "requirement" is alarming.
The value of the code is how well-formed the spec is + how well tested it is in the real world. So prompt / mockup cannot replace code.
Sure, an LLM can fix it, but that assumes your original spec sufficiently described the user requirements and wasn’t just a transcript of the original session trying to figure out how how to interface with all those dependencies in the first place.
Intentional or not, the rhetorical style of the title, plus the subtitle opening on the word "weird" before it's defined, has an ostracizing effect on me. I guess that it could have an ostracizing effect on others, though I can only speak for myself.
I was alive back then already, and was a relief to finally be able to afford GUI powered computers.
- A lot of TUIs that run on your own machine and have a mature GUI alternative are indeed not necessary. I once tried to replace Spotify with ncspot, which was exactly falling into the "TUI is more advanced" trap.
- The real target of this article is people who treat TUI as a kind of identity, not people who have to work in a terminal because of their job and therefore have plenty of good reasons to use TUIs.
But the title and the general tone are still too clickbaity, which is kind of annoying. In reality, apart from a small portion of TUIs that were created just to follow the trend and clearly have better GUI alternatives, most TUIs are really just side tools that grow out of one premise that we have to work in the terminal.
And even those flashy TUI tools still make life easier for people who work in a terminal. If you prefer GUIs, fine, you don't have to use them, but that doesn't mean they have no users or no value.
That’s exactly what I thought too when I read the article. When the author mentioned the essay In the Beginning Was the Command Line I instantly knew it. I thought to myself the audience of the article must be the people who had read the essay and allowed it to influence their taste, as well as the people who might not have read the essay but conversed with people who did.