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

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.

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

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

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

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.

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)

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.

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

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

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.

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

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.

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.

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.

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.

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

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.

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.

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

> 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.

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

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.

This was my first thought too. We already have terraform for repeatable, source controlled service provisioning and we have the relatively straightforward aws cli for ad hoc management. I don’t know that I really need another layer, and it feels quite risky.

The read-only hesitation seems overcautious. If you’re genuinely using it read-only, what’s the failure mode? The tool crashes or returns bad data - same risks as the AWS CLI or console.

The “middleware layer” concern doesn’t hold up. This is just a better interface for exploring AWS resources, same as k9s is for Kubernetes. If you trust k9s (which clearly works, given how widely it’s used), the same logic applies here.

If you’re enforcing infrastructure changes through IaC, having a visual way to explore your AWS resources makes sense. The AWS console is clunky for this.

All the use cases that popped into my head when I saw this were around how nice it would be to be able to quickly see what was really happening without trying to flop between logs and the AWS console. That's really how I use k9s and wouldn't be able to stand k8s without it. I almost never make any changes from inside k9s. But yeah... I could see using this with a role that only has Read permissions on everything.

The AWS APIs are quite stable and usually do exactly one thing. It’s hard to really see much risk. The worst case seems to be that the API returns a new enum value and the code misinterprets it rather than showing an error message.

I guess it's the kind of thing where you want an almost Terraform like "plan" that it prints out before it does anything, and then a very literal execution engine that is incapable of doing anything that isn't in the plan.

With properly scoped roles I would not be concerned

If only Amazon made it so simple

Different use cases. I want aws-cli for scripting, repeated cases, and embedding those executions for very specific results. I want this for exploration and ad-hoc reviews.

Nobody is taking away the cli tool and you don't have to use this. There's no "turns into" here.

Terminal electron.

Not a dumb question at all. I grew up using actual green screen terminals, and the advent of high-resolution colour monitors and applications with dark text on a white background felt like a blessing. I truly do not understand the regression to dark mode. It's eyestrain hell for me.

Unfortunately, I was unable to test in my light-background terminal, since the application crashes on startup.

My personal experience is mixed. Half the time, I get something usable, the other half I get something that prints light yellow on slightly-darker yellow or highlights an item with a dark blue background and dark green text. I'm sure there's something I can tweak in my terminal app to fix this, but it's easier to just avoid those apps.

You or the developer could piggy back on “aws configure export-credentials --profile profile-name —-format process” to support any authentication that the CLI supports.

I also care security part, but this is just beginning :) New features will be added iteratively based on community requests, and it seems there are plenty of good requirements in HN thread, thanks

Yeah, without SSO support this is a no-go for me too.

There was a resource handling problem, but it is fixed in 1.0.1 that you can try

I would like to know more about this. I love the resurgence of TUI apps but there is a samey-ness to them.

Anything in particular you liked about them?

Seems like everyone is interested in Rust, but yours was written in Go.

That was my first thought too, it looks like it was directly inspired by k9s according to the bottom of the readme.

Will be available soon ;) https://github.com/huseyinbabal/taws/issues/18

Oh this looks really interesting as well.

Can you tell me more about what do you mean by Neocloud and where are you exactly hosting the servers (do you colocate or do you resell dedicated servers or do you use the major cloud providers)

this is my first time hearing the term neocloud, seems like its focused on AI but I am gonna be honest that is a con in my book and not a pro (I like hetzner and compute oriented compute cloud providers)

Share to me more about neoclouds please and tell me more about it and if perhaps it could be expanded beyond the AI use case which is what I am seeing when I searched the term neocloud

Why?

Is it the best out there? No. But it does work, and it provides me with updates for my tools.

Random curl scripts don't auto-update.

Me downloading executables and dropping them in /bin, /sbin, /usr/bin or wherever I'm supposed to drop them [0] also isn't secure.

[0] https://news.ycombinator.com/item?id=46487921

Also, I find it is usually better to follow up with something like:

'It's better to use Y instead of X BECAUSE of reasons O, P, Q, R & S' vs making a blanket statement like 'Don't use X, use this other insecure solution instead', as that way I get to learn something too.

Also don't use Homebrew on MacOS because it screws around in /usr/local and still hasn't worked out how root is supposed to work.

Use Macports, it's tidy, installs into /opt/macports, works with Apple's frameworks and language configuration (for python, java etc), builds from upstream sources + patches, has variants to add/remove features, supports "port select" to have multiple versions installed in parallel.

Just a better solution all around.

Nice, download a random binary off the internet and give it your AWS credentials.

Please people, inspect the source to your tools, or don't use them on production accounts.

What's the problem with Homebrew?

> It's better to simply point at the binaries directly.

Binaries aren't at all signed and can be malicious and do dangerous things.

Especially if it's using curl | bash to install binaries.

What’s the issue with homebrew?

What's wrong with Brew?

As a user of immutable Linux (bazzite), I suggest speaking for yourself and not for others.

On my platform, Homebrew is a preferred method for installing CLI tools. I also personally happen to like it better on Linux than Mac (it seems faster/better).

https://docs.bazzite.gg/Installing_and_Managing_Software/

brew is for users of non-Arch distros who want to experience what using Arch feels like.

Why does it matter?

If you have permanent credentials then you are already in great danger. You should be using temporary credentials with something like Granted.

The crazier part is a reddit post on AWS was made for someone releasing a $3 a month closed source version of this, that received a lot of traction, but a bit of flack for being closed source was made 3 hours before the first commit. This guy 100% took the idea and the open source parts and recreated it to post here. Look at the readme and compare them. It is almost a 1:1 copy of the other. This dude is hella sketch. And if this is getting traction we are cooked as developers.

It looks like the first commit was just a squash and merge, I probably would never trust a public commit history as some kind of source of truth anyways. I'm curious what your issue is?

I think you’re vastly overestimating how difficult this type of application would be to an LLM. There’s no need to steal another code base…isn’t yours closed source, anyways?

You could probably get 90% of the way there with a prompt that literally just says:

> Create a TUI application for exploring deployed AWS resources. Write it in Rust using the most popular TUI library.

Making those accusations while hiding the fact that the “other developer” was you is extremely disingenuous.

Just need to pay monthly for Claude and run software that's propped up by a VC funded bubble. Due for enshittification if not shuttering.

Hardly the same.