461–470 of 579 posts
As a ratatui library maintainer, NO - please don't stop making TUIs ;) As a developer outside of that, I love the scratch the itch apps stuff mentioned in here. I have a vibe coded SwiftUI chess repertoire builder app that fits in that same sort of space that I'm currently working on, where I'd probably not have chosen to explore the idea if not for coding agents. I agree with the article that the terminal is an odd…
So...emacs
It’s much easier for the clanker to loop on testing / improving the TUI than a real GUI. It also means it can work on the app without an API/REST/HTTP/Java/Script ball of mud in the middle.
Earlier quoted context omitted.
A lot of us do the vast majority of our non-browser work on remote systems. GUIs are objectively bad for this
X Windows was invented on the 1980's and isn't the only way to graphically access remote systems. Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.
Genuine question, what is your alternative suggestion to accessing lower level features then? A hard time I have with GUIs is that their input/output can't be piped. It's much more cumbersome to try to automate a GUI than to automate something in the terminal.
Whilst I get that this is about TUIs, I do believe there is a reason for shell access due to automation. Good abstractions can be put into the GUI, but I'd argue that you should first build the abstraction, then put a GUI on top of it. AWS is a prime example, any of their APIs can be used w/out AWS Console.
Earlier quoted context omitted.
Yeahs ago I remember when my big bank switched from a TUI front end to a web front end for their front line staff. What originally took a few quick keyboard/tab combinations that was hard wired into employee muscle memory immediately took 2-3 times longer. Fortunately, the need to go into a physical bank doesn’t matter as much, but it’s still a regression…
The truth is that the web is a shit GUI framework. It's slow, clunky, incredibly resource intensive, hard to make uniform, verbose to code. It's terrible. The way the whole industry adopted it is understandable given the install base, but it's also probably a trillion dollar tax. I'd hate to see how much additional energy is used by billions of end-user devices running a rendering layer that is 100X heavier and more…
There should be public browsers and public search engines. The private incentives are too much and software built for public needs can be extremely cheaper than their private counterparts once you remove the need to support advertising services.
Earlier quoted context omitted.
The article is not against CLIs but TUIs. It’s extra mentioned that CLIs are mostly a good idea but TUIs aren’t.
> The article is not against CLIs but TUIs. Isn't it against both? Maybe I'm reading it wrong then, because things like these certainly seem against CLIs: > Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing indust…
> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.
Earlier quoted context omitted.
That's an indictment of ssh workflows not GUIs. RDP works fine but it's based on a full desktop experience. Despite having the technology, we don't have the ability to remote in and run a single graphical program in a single window with the same ease. We need something as seamless as Parallels for remote remote apps. But I guess we just settled on web apps.
Of course there is, waypipe, ssh -X, wayVNC on a headless cage (or sway with appropriate config) session.
What do you run like that day to day?