If writing a GUI was as easy and stable as writing a TUI, yeah we should write more GUIs. I can run practically any ancient TUI program on a terminal emulator, but running a GUI program that uses an older version of GTK means going through dependency hell to compile and install all the old library versions. If they even compile with the new GCC... I really wish we had a standard way to spawn a webview (or similar) and connect stdin/out to it.
Stop Making TUIs
241–250 of 579 posts
Re: Stop Making TUIs
#242Earlier quoted context omitted.
> 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?
TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham. Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy…
> TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform.
TUIs look bad everywhere, so that's strictly worse
Re: Stop Making TUIs
#243Just adding in my perspective:
TUIs, at least to me and some friends in my circles, do something that native applications don’t: demand focus from the user.
Sure, modern terminals and TTY environments have visual tabs and virtual terminals that let you quickly toggle between multiple apps, and you can of course manually code your screen to split apps across a single “window” if you really want to get into the guts of things.
But for several folks in my close circles (myself included), the fact that each TUI occupies an entire screen by default, forces us to focus on what’s going on and what tasks we’re trying to accomplish in a way native UIs don’t. On the desktop I can flit between Discord and Telegram and multiple games and several Firefox windows full of tabs and the video encode I’m working on and hey did that bank transaction go through let’s check my email except UGH music streaming went off the rails so let me go back to my client and-
You get the idea. For folks who lack the neurotransmitters to maintain consistent focus or wave off distractions, a terminal environment acts as an accessibility device in and of itself. btop on 1, irssi on 2, Hermes (Qwen 35B) on 3, with 4 as my primary workspace and 5 as a fallback. Simple. Clean. Efficient. Lightweight.
I generally concur with the author that we should be “summoning” (I love that word for reasons that deserve their own essay/comment) more native UI apps that are as information-dense as, well, Bloomberg Terminal. There’s no reason we can’t build something as powerful and focused for the everyman for, say, inventory collections, or K8s constructs, or network architecture, all in a native UI. There’s nothing wrong with the GUI, only that at some point we let ourselves get suckered for the narrative that GUIs have to be easy, simple, and opaque, as opposed to transparent and (logically) complex. We can and should build GUIs that flow logically like the commands they’re executing behind the scenes; hell, we should be able to open a console log of every action we took in the GUI and the associated command(s) it executed, so we can better learn to transpose from GUI to CLI ourselves and build more capable or complex automations.
GUI isn’t bad. TUI isn’t bad. What’s bad is presuming one or the other is superior to everything (or for everyone) else, or worse, assuming one cannot function in a given way comparable or equivalent to the other.
Re: Stop Making TUIs
#244You can't tell someone who doesn't like the command line why it's so awesome.
EDIT
> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.
Oh, right. I can see that, but I go the other way: When I have a CLI, don't give me GUIs; give me files. Actually, just give me files and daemons. I'll do the rest, thank you!
Re: Stop Making TUIs
#245Counterpoint: Build more TUIs in Rust using Ratatui: https://ratatui.rs/ Why? Because just look at the examples on that page.
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.
Re: Stop Making TUIs
#246Earlier quoted context omitted.
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.
Yes, but GUIs are by default mouse driven, very rarely one can see a keyboard driven one (I haven't seen any). And TUIs are only keyboard driven. So the choice for speed if you don't need graphics is always - TUI (or CLI).
> And TUIs are only keyboard driven.
Plenty of TUIs support mouse to various extents too. Claude Code is an obvious example (try the scroll wheel for example).
I agree with you that TUIs are keyboard driven first though - and so you can be certain it will work well.
Re: Stop Making TUIs
#247You 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.
> They live in a tab in my terminal.
So you can't even immediately switch to your app and don't see it in an OS-integrated list?
Re: Stop Making TUIs
#248Earlier quoted context omitted.
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.
Yes, but GUIs are by default mouse driven, very rarely one can see a keyboard driven one (I haven't seen any). And TUIs are only keyboard driven. So the choice for speed if you don't need graphics is always - TUI (or CLI).
Emacs is primarily keyboard driven.
Re: Stop Making TUIs
#249Isn’t the GUI version of a TUI just an Electron app?
Re: Stop Making TUIs
#250Benefit of TUIs is that sometimes they are extension of CLI. Sometimes I can use `du` to check what uses so much space, but sometimes ncdu is better for me. And the best part - I can use both when I ssh to another machine, using the same command line, without thought. While GUIs need added thought, to switch from CLI to GUI on the remote one would need to use a different interface, or have X11 forwarding on (which is…
> And the best part - I can use both when I ssh to another machine,
Exactly. I'm currently on vacation and has checked in on long running Claude Code sessions over ssh every few days. I could have used X11 forwarding or VNC if I needed a GUI app, but the connection I'm on is currently slow and unstable, and using text mode has been far more palatable, especially since I can use tmux (or in the case of Claude Code, just using "claude agents" and let it background the sessions itself).