For some basic stuff like vim it works fine. But for almost everything else I'd rather a regular CLI tool or a web interface. I suspect a lot of the popularity comes from people who want to feel like a hacker using 10 terminal windows, but actually want a GUI like experience.

▲

ulrikrasmussen an hour ago | parent | next [-]

For me, TUIs compensate for the fact that I can't get good remote GUI rendering on Linux. Yes, X11 tunneling exists, but the experience has always been abysmal for me for anything not hosted on a machine that sits on the same LAN as the client. For Wayland I don't even know if such a thing is possible since I don't think the architecture supports it.

But the terminal is just fundamentally the wrong basic abstraction on which to build a structured GUI, it just happens to require few enough bits to be sent over the wire that it actually works reasonably well over SSH as opposed to pushing graphics.

	▲	bitwize 3 minutes ago \| parent [-]
		> Yes, X11 tunneling exists, but the experience has always been abysmal for me for anything not hosted on a machine that sits on the same LAN as the client. Good performance with X11 is possible if you avail yourself of the X11 primitives. This is where Lilith Nyan-Nyan (she/they/it, mastodon lilith@catbox.gay), core Wayland developer, pipes up and says "OwO nobody develops like that anymore :3 everything is rendered client-side on the GPU, and then zero-copy transferred to the compositor for display... really that's the only function the X server has anymore, and wayland is a better architecture for this uwu" But what Mx. Nyan-Nyan, and a lot of developers of her/their/its generation don't realize, is that in the past Unix developers strove to write programs with UIs that were usable across network lines, and availed themselves of the X11 protocol's graphical primitives to do just this. Emacs, for example—particularly emacs-lucid—is incredibly snappy even when an Emacs in the cloud is rendering to your local X server. If you write things the modern way, which developers largely do assuming a 100% local display, then in the remote case the X client will have no choice but to ship uncompressed pixmaps of each frame over the network to the X server, which greatly slows things down. What we are seeing is that "the modern way" is beginning to be applied to terminal apps as well! Claude Code, for instance, has a React-based layout and rendering flow (does it use Ink?), and redraws the entire chat history on each update, leading to the slowdown and flicker problems it had. It would be absolutely unusable over, say, the kind of 9600-baud link that was commonplace back when people used actual terminals to connect to large systems (and ran full-screen apps in those terminals!). It's only a bloat cycle or two more before these programs start to struggle over a typical ssh link, too! We've utterly lost the plot when it comes to software.

▲

helterskelter 18 minutes ago | parent | prev | next [-]

I dunno, pre-LLM TUI's at least tended to be okay, and keyboard navigation was a first class citizen. Besides, if you were using a TUI instead of a GUI then you basically always ended up saving memory/battery life, and TUI programs are generally more portable than trying to run some ancient GUI program.

I typically prefer CLI myself but having a TUI to manage torrents for instance was much more ergonomic.

	▲	SchemaLoad 14 minutes ago \| parent [-]
		For almost every tui, a webui works better imo. Most torrent clients offer a web management ui and it's always going to be easier and more feature filled using a platform that was actually designed for it rather than hacking a gui in to the terminal.

▲

xboxnolifes 3 hours ago | parent | prev | next [-]

Obviously people want GUIs. That's why TUIs should be compared to GUIs, not to CLIs. TUIs are nice since you get a lot of the benefits of a GUI, without having to leave the context of the terminal.

▲

yellowapple 2 hours ago | parent [-]

I feel like the better solution here (than trying to shoehorn a GUI into an interface meant for text) is to make terminal windows graphically-aware, like how things work in Plan 9.

	▲	SchemaLoad 24 minutes ago \| parent [-]
		At that point what you want is just a tiling window manager rather than a terminal that supports GUIs.

▲

zbentley 3 hours ago | parent | prev | next [-]

This. A lot of folks picked it up for that reason when they were young and now are terminal-all-the-things out of sheer inertia.

▲

bee_rider 3 hours ago | parent | prev [-]

Vim is special because 99% of what we do is editing text, and it is the text editor—the importance of that task overcomes the poor discoverability of a TUI. Most other programs should be CLI, so they can fit in the conventional command line toolbox.