[dbish]

I’m relatively certain it’s just this at the end of the day. Everything I see people doing in their custom built TUIs or claude/codex CLI can be done, likely even easier, in a simplified IDE or easier to scan UI, but it feels nice/cool/cyberpunk/work-like to look like you’re doing more.

Everyone will have a “reasonable” explanation though for why they have to stay in the terminal even when they aren’t really coding anymore and it wouldn’t be hard to have a window next to your terminal if you really have to, but live and let live. Whatever makes you happy as be all become managers.

I too like a cyberpunk interface even if it’s last the need :)

[allthetime]

It is much easier to quickly generate a usable tui for simple monitoring and management than a usable gui. Go + lipgloss + bubble tea and a single prompt will give you whatever you need in a minute or two - much faster to compile and no platform specific issues. I can’t speak for anyone else, but I do a lot of work in the terminal still and I’d much rather stay in that context then open up yet another window

[majormajor]

> I can’t speak for anyone else, but I do a lot of work in the terminal still and I’d much rather stay in that context then open up yet another window

I do a lot of work in the terminal and that's exactly why I'd rather have other windows to the side so that my terminal can stay exactly focused on what I'm doing there. Those other windows might also be terminals, but I have a big screen, and I want to make use of it to see things all at once. A GUI gives far more flexibility for arranging those multiple views.

I've sat with coworkers taking two to twelve keystrokes to flip between things that I just have side by side in separate IDE windows, browser windows, or tabs... or can switch between with a single click instead of those keystrokes.

[kajman]

Window managers are more flexible than multiplexers, but I also think there's a higher floor of effort juggling multiple separate GUI programs than going between tabs and panes in a terminal emulator.

Multi-monitor terminal juggling also probably loses out to GUIs, though for me it's usually IDE or Browser on one and multiplexer on the other. One big zellij session connected to multiple terminal emulators is probably the best way I could think to handle that.

[rmunn]

> a higher floor of effort juggling multiple separate GUI programs than going between tabs and panes in a terminal emulator.

Depends very much on your window manager. Tiling window managers such as Hyprland let you open multiple windows and it will automatically arrange them side-by-side. Want one of them to be 60% and the other 40%? No problem, there's a keyboard shortcut (configurable) for that. Have four windows open in a grid arrangement and want to switch between them? Just slide the mouse, no clicking needed so the movement can be as rough and imprecise as you want, OR if you don't want to take your hands off the keyboard then SUPER+arrow keys (also configurable) will move the focus to the next window in that direction. (And if you are in focus-follows-mouse mode then it also moves your mouse cursor to be in the middle of the focused window, so you won't lose window focus by accidentally bumping your mouse and moving it one pixel). Keyboard shortcuts for maximizing and un-maximizing windows, for throwing them onto other workspaces and switching between workspaces...

I throw windows around my screen all the time, and rarely take my hands off the keyboard to do it. It's the fastest, most flow-like window manager experience I've found yet.

[pocksuppet]

This used to not be the case - we've regressed. In the distant past you could just drag a couple of widgets onto a form and update them from a timer.

[tempaccount5050]

Not anymore it isn't. "Claude, make this a web app".

[allthetime]

Just what I need! A bloated react app to manage my systemd units

[logicprog]

Just use something like Tk or wxWidgets.

[tempaccount5050]

So just tell it html only if you want.

[allthetime]

How does the browser interact with the os? A tui exe has direct access. With “only html” now we need a server of some kind. How is multiple layers and running processes superior to a thin terminal based wrapper around the relevant io?

That said, obviously it depends on the use case. I’m not going to make a tui to interact with locations on a map - a web app makes a lot of sense in that case. But something like lazydocker makes sense more sense as a light terminal based program

[sophiabits]

A browser is OOM more expensive to run than a terminal app, regardless of what you're running inside said browser

[vineyardmike]

I've literally never met anyone in real life who used a computer that didn't already have a browser running 24/7

[eVeechu7]

Is that because they are much more likely to pay the ultimate price at the hands of the OOM killer?

[wild_egg]

Can get a GUI with the same prompt if you tell it to use TCL/tk instead of Go + Charm stuff

[dbish]

It’s very easy to do the same thing in a variety of ways and simple guis are basically solved by Claude/codex for almost anything.

[mr_mitm]

TUIs already increased in popularity before agents became a thing. The low latency, the ease of remoting and the limited screen real estate which forces the developer to carefully design the interface are genuine advantages. I've been using mutt, vim, tig, tmux, newsboat, etc for over a decade at this point, and the cyberpunk feeling faded quickly.

[setr]

The low latency and instant startup is by far the primary value add imo. Nothing else comes close.

The inherent lack of UI bloat is an added bonus.

[regexorcist]

No it can never be the same. The terminal is about not having to switch from the keyboard. My entire workflow is tmux panes with different TUIs and terminals. Not to mention performance, with a neovim IDE you may have tens of them open in different panes for example. I wouldn't try that with VSCode.

[logicprog]

You can make even lighter weight and just as keyboard driven GUIs. The only downside, as you say, is them not integrating with Tmux.

[regexorcist]

Projects like opencode are making the distinction between GUI and TUI almost meaningless. And that "only" downside is a massive, deal-breaking one. At this point I only have a browser besides the terminal, and I can see that going away soon for the most part thanks to LLMs.

[ghusto]

It isn't, at least for me. I choose between GUI and terminal apps based on which one is easies. Sometimes the "easy" option really isn't easy at all.

[xiaoyu2006]

But GUIs are hard to built - mainly because of tech debts around all three major platforms. But nontheless displaying graphics is harder than outputting control chars.

[PunchyHamster]

You could whip up decently usable UI in Delphi far quicker than similar one in any TUI framework.

The problem is that world went away from that and into HTML/CSS/JS/DOM mess that makes simple UI things hard and complex UI things slow and/or hard, on top of the bloat.

[smackeyacky]

This is a recent development.

VB6 could have you roll a GUI interface in minutes, so even trivial tasks could have a GUI.

The tools for CDE on Unices were arguably even better but CDE never really got any momentum.

That it’s tough to put together a GUI now is definitely a regression and Microsoft shooting themselves in the feet regularly over the last 25 years is squarely to blame.

[james_marks]

Hot take: TUI’s default to providing utility, GUI’s are prone to extra style/bloat.

Obviously both are capable of the other.

The vanilla HTML styles look bare, so you have do _something_. TUI’s look sort of cool in their simplest form.

[keyringlight]

It's an aspect I've wondered about, constraints do make you consider what's essential. For example in btop (screenshot in the article) the graphs are rendered with dots at low resolution, if there was another version where those graphs were full resolution is it telling you meaningfully more?

[rmunn]

Since the dots in btop's rendering are using the Braille characters, meaning you get six dots in the space that would be taken up by one alphanumeric character, the resolution on those dots is surprisingly high. A maximized terminal on my screen is size 316x86, so that's 316×2 x 86×3 = 632x258 of "Braille dot resolution" (a term I just made up) available for the graphs. Sure, that's lower than the 2560x1600 pixel resolution of my screen, but you're entirely right to ask "Does that really matter?" The graph would be smoother with about 4x more horizontal pixels and 6x more vertical pixels to work with, but I doubt I would glean any more information at first glance.