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?
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
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
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.
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)
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.
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 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.
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.
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
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.
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.
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.
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.
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.
More broadly, I have concerns about introducing a middleware layer over AWS infrastructure. A misinterpreted command or bug could lead to serious consequences. The risk feels different from something like k9s, since AWS resources frequently include stateful databases, production workloads, and infrastructure that's far more difficult to restore.
I appreciate the effort that went into this project and can see the appeal of a better CLI experience. But personally, I'd be hesitant to use this even for read-only operations. The direct AWS cli/console at least eliminates a potential failure point.
Curious if others have thoughts on the risk/benefit tradeoff here.
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.
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.
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.
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.
I run a neocloud and our entire UX is TUI-based, somewhat like this but obviously simpler. The customer feedback has been extremely positive, and it's great to see projects like this.
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
Embarrassingly dumb question: if you’re one of the few users who don’t run a dark background terminal … how well do these TUI render (in a light background)?
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.
Looks great! If you have multiple AWS accounts in your org, you probably want to use something like aws-sso-util to populate your profiles so you can quickly swap between them
> // TODO: Handle credential_source, role_arn, source_profile, sso_*, etc.
So it does not support any meaningful multi-account login (SSO, org role assumption, etc), and requires AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY. That's a no-no from security POV for anything in production, so not sure what's the meaningful way to use that.
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
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.
Nice! A while back I had started something similar for Azure but it never really got traction (or nearly as polished as this!). It's a rough proof of concept but maybe it'll be useful to Azure users:
I wish more TUI designers would spend some time playing with Hercules and experiencing the old "mainframe" way of arranging interfaces. Those guys really knew what they were doing.
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.
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).
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.
kristiandupont|1 month ago
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|1 month ago
MrGilbert|1 month ago
TUI also means that I do not have to memorize an infinite amount of command line parameters.
I really like well-made TUIs.
rgoulter|1 month ago
For some reason, expressive keyboard-driven interfaces aren't as popular in GUI interfaces.
lucideer|1 month ago
- 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
Cthulhu_|1 month ago
victorbjorklund|1 month ago
oneeyedpigeon|1 month ago
mystifyingpoi|1 month ago
ashu1461|1 month ago
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.
wtetzner|1 month ago
thiht|1 month ago
freeplay|1 month ago
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|1 month ago
d4rkp4ttern|1 month ago
whatever1|1 month ago
Http servers are not installed by default, and they are a pita to configure / secure.
rockwotj|1 month ago
chilli_axe|1 month ago
benterix|1 month ago
perrygeo|1 month ago
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|1 month ago
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|1 month ago
israrkhan|1 month ago
unknown|1 month ago
[deleted]
tianqi|1 month ago
More broadly, I have concerns about introducing a middleware layer over AWS infrastructure. A misinterpreted command or bug could lead to serious consequences. The risk feels different from something like k9s, since AWS resources frequently include stateful databases, production workloads, and infrastructure that's far more difficult to restore.
I appreciate the effort that went into this project and can see the appeal of a better CLI experience. But personally, I'd be hesitant to use this even for read-only operations. The direct AWS cli/console at least eliminates a potential failure point.
Curious if others have thoughts on the risk/benefit tradeoff here.
falkensmaize|1 month ago
3uler|1 month ago
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.
zmmmmm|1 month ago
pgroves|1 month ago
zeroimpl|1 month ago
nfRfqX5n|1 month ago
kylehotchkiss|1 month ago
bdbz|1 month ago
lherron|1 month ago
viraptor|1 month ago
Nobody is taking away the cli tool and you don't have to use this. There's no "turns into" here.
toomuchtodo|1 month ago
latchkey|1 month ago
ssh admin.hotaisle.app
Imustaskforhelp|1 month ago
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
alberth|1 month ago
deepspace|1 month ago
Unfortunately, I was unable to test in my light-background terminal, since the application crashes on startup.
oneeyedpigeon|1 month ago
sylens|1 month ago
ronbenton|1 month ago
mrichman|1 month ago
huseyinbabal|1 month ago
bcb_1000|1 month ago
[deleted]
shushpanchik|1 month ago
So it does not support any meaningful multi-account login (SSO, org role assumption, etc), and requires AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY. That's a no-no from security POV for anything in production, so not sure what's the meaningful way to use that.
huseyinbabal|1 month ago
zeroimpl|1 month ago
fosron|1 month ago
brendank310|1 month ago
https://github.com/brendank310/aztui
NSPG911|1 month ago
themafia|1 month ago
jxdxbx|1 month ago
wilkystyle|1 month ago
jbreckmckye|1 month ago
jedimastert|1 month ago
politelemon|1 month ago
OptionOfT|1 month ago
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.
colesantiago|1 month ago
> 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.
rswail|1 month ago
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.
yarekt|1 month ago
Please people, inspect the source to your tools, or don't use them on production accounts.
dangus|1 month ago
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/
frenzcan|1 month ago
jbreckmckye|1 month ago
purerandomness|1 month ago
stephc_int13|1 month ago
otterley|1 month ago
dmacvicar|1 month ago
huseyinbabal|1 month ago
unknown|1 month ago
[deleted]
rbanffy|1 month ago
utkayd|1 month ago
dent9|1 month ago
serpix|1 month ago
petterroea|1 month ago
huseyinbabal|1 month ago
tvbusy|1 month ago
bcb_1000|1 month ago
jedimastert|1 month ago
bizim_oralar|1 month ago
alexpadula|1 month ago
very_clumsy|1 month ago
[deleted]
unknown|1 month ago
[deleted]
gogasca|1 month ago
[deleted]
unknown|1 month ago
[deleted]
acedTrex|1 month ago
[deleted]
johnj-hn|1 month ago
[deleted]
blutoot|1 month ago
nirushiv|1 month ago
[deleted]
bcb_1000|1 month ago
[deleted]
ktevfik|1 month ago
[deleted]
dionian|1 month ago
[deleted]
Yanael|1 month ago
[deleted]
bschmidt25001|1 month ago
[deleted]
bschmidt25013|1 month ago
[deleted]
bschmidt25013|1 month ago
[deleted]
bcb_1000|1 month ago
songodongo|1 month ago
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.
bcb_1000|1 month ago
catlifeonmars|1 month ago
mikert89|1 month ago
saintfire|1 month ago
Hardly the same.