[kristiandupont]

Only tangentially related, but: what is the appeal of TUI's? I don't really understand.

The advantages of CLI's are (IMO) that they compose well and can be used in scripts. With TUI's, it seems that you just get a very low fidelity version of a browser UI?

[chazhaz]

The advantage of TUIs is that you get a low-fidelity browser UI that doesn’t need to be exposed to the internet, that can be run remotely via SSH, which doesn’t ship you megabytes of JavaScript, and which works equally well on everyone’s machine

[spwa4]

Don't forget about the speed and the keyboard-only navigation.

[oneeyedpigeon]

> doesn’t need to be exposed to the internet

[PWAs: Offline and background operation](https://developer.mozilla.org/en-US/docs/Web/Progressive_web...)

> that can be run remotely via SSH

Fair

> which doesn’t ship you megabytes of JavaScript

Not required at all; that would be a decision the app makes and not inherent to the medium

> works equally well on everyone’s machine

Provided they're using a compatible terminal with a compatible color scheme that doesn't just make everything unreadable.

[infogulch]

> > which doesn’t ship you megabytes of JavaScript

> that would be a decision the app makes

OK but as soon as some moron with a Product Manager title gets their grubby little fingers on it the app does start shipping megabytes of JS in practice. TUI's can't, that's the advantage.

[wubrr]

You can run a web UI locally, without exposing it to the public internet, and access it remotely via SSH.

> which works equally well on everyone’s machine

Why are you so sure it runs equally well on everyone's machine? Even big popular TUIs like Claude Code do not really accomplish this.

[MrGilbert]

They are usually faster to create and pretty much cross-platform. They should also work great with screen readers, though that is only an assumption.

TUI also means that I do not have to memorize an infinite amount of command line parameters.

I really like well-made TUIs.

[rgoulter]

Practically? The best keyboard-driven programs are (incidentally) TUIs.

For some reason, expressive keyboard-driven interfaces aren't as popular in GUI interfaces.

[peiskos]

My issue with TUIs is the lack of a simple interaction model. Every tool invents its own navigation style like vim bindings, custom key combos, mouse-driven flows and there’s no common fallback. In GUIs, the mouse is always there if nothing else. Even basic things like tabbed navigation can become confusing in TUIs sometimes

[rgoulter]

Sure, for a lowest-common-denominator, GUIs and websites will let you use a mouse. That's great for if you want to use a tool & don't want to take time to get familiar with it.

There are some things which are inherent to GUI or CLI interfaces.. but, overall, nothing ensures a TUI will be good, and nothing prevents a GUI from providing a good interface. -- The distinctions are generally going to be program specific.

So e.g. using openlens (GUI) vs k9s (TUI) vs kubectl (CLI).

[lucideer]

Apart from the apparent comparative ease of creation relative to GUIs (I suspect Electron apps may be easier than TUIs), I think the main benefits from a user perspective seems to be down to cultural factors & convention:

- TUIs tend to be faster & easier to use for cli users than GUI apps: you get the discoverability of GUI without the bloated extras you don't need, the mouse-heavy interaction patterns & the latency.

- keybindings are consistent & predictable across apps: once you know one you're comfortable everywhere. GUI apps are highly inconsistent here if they even have keybindings

- the more limited widget options brings more consistency - GUI widgets can be all sorts of unpredictable exotic

- anecdotally they just seem higher quality

[tracker1]

For that matter, with modern terminals, you can still do mouse interactivity as an option. I think that working over an SSH terminal is pretty nice in and of itself even if you can self-host a web application.

I've almost always got my terminal app open anyway, in the case of VS Code, I don't even need to switch to another app to use it.

[Cthulhu_]

Before Windows / GUIs, everything was a TUI. Some of those applications were kept around for a long time even when Windows was mainstream, because they were faster. If you've ever seen an employee (or co-worker) work in one of those applications you'll see it. They can zip through screens much quicker than someone doing point and click work.

[cube00]

It's truly an amazing sight, our payroll system was all text based screens. I had a question and the clerk ripped through like 10 screens to get the information I needed, we're talking 200ms human reaction speed through each screen.

I also worked with a mythical 10x developer and he knew all the Visual Studio keyboard shortcuts. It was just like watching that payroll clerk (well, almost, we had under-specced machines and Visual Studio got very slow and bloated post v2008), I don't think I ever saw him touch the mouse.

[victorbjorklund]

Faster and easier to use. I love for example Lazygit. It’s the fastest way to use git (other than directly as a cli of course but if you want some graphical info lazygit is great)

[oneeyedpigeon]

You get a low-fidelity version of a browser UI with guaranteed keyboard support. If web apps had the same level of keyboard support, TUIs would be less appealing.

[graemep]

They also expose relevant keyboard actions.

The popularity of TUIs is a result of the poor usability of current GUIs.

[coredog64]

In my experience, the AWS UI is actually pretty good at keyboard usability. The biggest issue with the UI is how long it can take API calls to fill in the data, and that would be the same for both the browser and a TUI.

[mystifyingpoi]

Look up k9s, it's a great example. But as sibling comments say, it's all keyboard driven and most actions are single keypresses.

[ashu1461]

I had the same doubt. With CLIs you can make your own custom shortcuts, LLMs can use it to get things done for you as well. With TUIs I think either these are hobby projects or meant for people who are obsessed with speed.

Though speed impacts are also something which I am uncertain about. Comparing Vim with IDEs, for sure there will be few things which are faster in vim but decent no of things which can be done faster in an IDE as well, so can't comment on your overall speed gains.

[esseph]

Tuis are fine if you've got a bunch of pets or cattle you admin over ssh

[wtetzner]

For one thing, you don't need to run them in a browser.

[thiht]

I recently started using k9s after using kubectl for a while. It's just faster and more convenient. A well made TUI also offers a bit more discoverability than a CLI. If you know exactly what you're looking for the CLI is fine, but if you need to explore a little bit, a TUI is better.

[freeplay]

Memorizing CLI commands and typing/editing them over and over can be very time consuming.

Use k9s for example. Let's say you want to determine where the value of an environment variable is coming from.

1. 'kubectl get deploy -n example' (find the name of the deployment in question)

2. 'kubectl describe deploy example-app -n example' (determine where the value for the env var is coming from)

3. 'kubectl get cm example-app-config -n example -o yaml' (check the value of the referenced key in the config map)

This is a very basic example but you can see where it lead to slow debugging that is made even slower by its propensity to typos and the need to look up command syntax. Once you get comfy in a well designed TUI, you can fly through this process in 10 seconds.

[jama211]

The appeal is I can use it with just a terminal connection to the server

[d4rkp4ttern]

TUIs can be self explanatory if designed well. Ideally the same tool would have a CLI mode with JSON(L) formatted output, launched with a flag like —json so that it can be composed (unix-like) with other CLI commands, and also usable by LLM-agents, with jq etc. This is what I do in a TUI/CLI tool I’ve been building

[whatever1]

The only real advantage is that you have access to a UI—ish everywhere, because the ssh server is running everywhere by default (at least at machines you would want to connect to).

Http servers are not installed by default, and they are a pita to configure / secure.

[rockwotj]

you also get a very slimmed down interface that is usually way faster to load. one of the reasons I love HN is that it is super snappy to load and isn’t riddled with dependencies that take forever to load and display. Snappy UIs are always a breath of fresh air.

[cube00]

> Snappy UIs are always a breath of fresh air.

UIs used to be more responsive on slower hardware, if they took longer then the human reaction time, it was considered unacceptable.

Somewhere along the line we gave up and instead spend our time making skeleton loading animations as enticing as possible to try and stop the user from leaving rather then speeding things up.

[chilli_axe]

In addition to what other commenters said - TUIs can be installed on a server and used over SSH

[qudat]

This is the part that I like the most, which is why I created https://pico.sh

Further, when building ssh "apps" you can build out tooling for client clis that already exist (e.g. rsync, sftp, scp, sshfs). This provides ergonomics because now users aren't required to install extra tools to deploy static sites, for example.

The entire experience is pretty seamless since all developers use SSH anyway.

[makapuf]

Well CLI and web UIs can also be used remotely. (Arguably even x11 apps can.)

[cube00]

Even with compression on, running most apps like a web browser over x11 forwarding, is slow to the point of almost being unusuable.

However running web apps over forwarding is pretty decent. VS Code and pgAdmin have desktop like performance running in the browser SSH port forwarded from a remote server.

[benterix]

Many tools offer both CLI and TUI interface. TUI is especially useful at scale, when you need to deal with a large amount of resources efficiently or have a good overview of the whole environmtnt faster - e.g. *top, k9s, Midningt Commander etc.

[perrygeo]

> low fidelity version of a browser UI?

That's the point. For me, with very few exceptions, modern web UI is steaming pile of dogshit - no consideration for user's attention, speed, or usability. TUI are extremely low fidelity; there's nowhere to hide all that enshitified cruft! Stripping the functionality down to its bare essence vs navigating a bespoke web UI with the design aesthetic of clown vomit. I can tell you which one is more productive for me.

[nobleach]

I can give an anecdote if that's helpful. Imagine you're wanting to download an object from S3. You start to type out the command in your CLI. You hit enter, only to realize, see that the object is not found. You have a typo somewhere... but where? The bucket is huge so, you resort to listing the contents and passing the results through grep. Then you copy the object to the clipboard so that you can edit your original command.

I see one of the other comments mentions K9s. The exact same use cases manifest with that tool. YES, if it's just a one-shot, nothing beats the CLI. Many things where you need to investigate the resources a bit more, lend themselves to a TUI (or GUI if that's your thing).

I come from an era where folks could fly through tasks on dumb terminals. (AS/400 apps). The moment we gave them "better" gui tools, they slowed way down. No matter how many times we told them, "you can still use your TAB and ENTER keys!" TUIs were just a sweet spot.

[korse]

Sometimes a gui is helpful for things (such as monitoring) but you don't want to leave your terminal because it screws with your workflow.

[israrkhan]

I was skeptical too, but after trying lazygit, lazydocker, k9s and a few more TUI programs, I can see the value.