Tbh in a time where more and more applications are shipped as vibecoded electron based bloated bug-collections that are slow and take stupid amounts of resources i'd rather have even more TUI's than less.....
Stop Making TUIs
211–220 of 579 posts
Re: Stop Making TUIs
#212Earlier quoted context omitted.
TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham. Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy…
> TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. So because TUIs look universally bad, they're better than cross-platform GUI?
> cross-platform GUIs always look bad outside of the "main" platform
qBittorrent looks great on KDE, and would look great on macOS too if they used native icons (I’ve made a theme for that but was too lazy to install it when I was switching laptops). No idea about Gnome and Windows, but probably alright as well.
So, Qt can get you a long way. But you should of course adapt your app to platform conventions and guidelines.
Re: Stop Making TUIs
#213Earlier quoted context omitted.
Countless reasons. Invent a gui client environment that is universal, works the same way everywhere, over any kind of channel, and is already implimented and supported everywhere, and utterly weightless in all dimensions (ram/cpu/network), and then you might be able to ask that question without it being incredibly ignorant. Today the closest you might be able to say is web/electron, which is gross on all counts. If a…
HTML/Javascript would like a word
we need a way to access locally running web apps without doing an ugly http://localhost:8022 and having to remember that.
I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth.
Re: Stop Making TUIs
#214As 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…
> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc. Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?
there's a million gui frameworks under the sun and i still haven't found one that feels like what everyone has been asking for:
good dx, cross platform, fast, not ugly.
pick i dunno 2 or 3.
tui's get to check 2 or 3 of these just like any other gui library. somehow there still isn't a silver bullet here.
now i personally don't build tuis but guake style dropdown simple command and i have some other thing someone made open immediately running in ghostty? hell yea. with that said yes there are some stupid tuis out there that are anything but simple.
Re: Stop Making TUIs
#215Tabs vs spaces. I’ve always appreciated the positive side of TUIs and appreciated less the positive side of GUIs. I didn’t grow up with a computer at all and in one of my first adult jobs I had to use a TUI at Papa John’s for punching in orders, it was 20x faster than anything I used after it at other restaurants that were GUI driven (keyboard speed wins for me, fit my brain perfectly). I think I learned it in 5 minu…
I like TUIs for largely the same reasons as you, but I don't think this is actually a valid criticism of the article. It specifically addresses this by pointing out that you can make your GUI keyboard driven if you want to, so this isn't really an advantage of TUIs per se. It just happens that TUIs tend to be keyboard focussed while GUIs tend to be mouse focussed. But that's a design choice rather than an inherent pr…
> I didn't really need to see a million examples of the author's vibe coded slop before getting to the topic which the title suggested the article would be about.
Agreed. One would hope the article would go into detail of how to make a great GUI (including tips on how to make sure it’s easy to navigate with a keyboard).
Re: Stop Making TUIs
#216Maybe on macOS you have great APIs, libraries and toolkits for making high quality GUIs, but if you're wanting to write open source software or target open source platforms, your options are limited and poor. On the Linux/BSD side, most toolkits are of not great quality, you'll inherit all sorts of subtle bugs and quirky behaviours. Most of the software that's of _great_ quality doesn't use the toolkit, but interface…
Use Qt or Flutter
qt is exhausting. flutter is actually awesome these days but the last thing i want to do is commit to dart
Re: Stop Making TUIs
#217TUIs are by definition keyboard first.
TUIs are a creative constraint.
TUIs are an invitation for programmers.
TUIs are doing "less" to render.
TUIs don't need to be "responsive".
Hello World is TUI.
Re: Stop Making TUIs
#218Make guis where guis make sense. I, for one, like to stay in my tmux session as much as possible.
And sure, for programs for one go ham on the ui.
Re: Stop Making TUIs
#219Going into this article my attitude was "don't tell me what to do!" but I kind of see his point.
Back in the late 1980s, there was no question—the Mac changed everything, and everyone agreed that graphical was the superior interface. But we in the Unix world were slow to convert fully, because of a couple of problems:
* designing GUIs is hard, especially for programmers;
* writing GUI code is hard (and often tedious).
So good GUI apps really came from teams of elite designers and developers. The best ones all worked for Apple. There was an acceptable second tier that all came from major companies. If you wanted to write a custom one-off tool for yourself, however, you'd be in for some pain and the result would be jank.
But LLMs solve both problems. Point Claude at a description and some mockups of an app, and it will give you that app, or at least a slick-looking prototype that is suitable for your use if not the wider market's. So we no longer have an excuse. ALL our apps should be graphical, because creating graphical apps is now easy.
Re: Stop Making TUIs
#220Earlier quoted context omitted.
HTML/Javascript would like a word
we need a way to access locally running web apps without doing an ugly http://localhost:8022 and having to remember that. I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth. So: http://claudecode.local
Won't that be cluttered by various random processes listening via 0/0? Perhaps we need a standardized service that web apps can register with.