Unfortunately we seem to live in an era where your mainstream choices for a cross platform app are "Electron taking 1GB when idle" and TUI.
Stop Making TUIs
281–290 of 580 posts
Re: Stop Making TUIs
#282> shorthand inputs that make common operations (like “take the gradient of this expression”) quick to type
There's a shorthand that derives from the Phoenician string instrument : nabla . Latex has it as \nabla
Re: Stop Making TUIs
#283Tabs 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…
What you're comparing is really "keyboard-driven" via "mouse-drive". A GUI can be keyboard-driven and as fast as a TUI. The sad truth is that the status quo for GUIs is absolutely terrible, and most were rushed out and not properly tested to check if they're really usable without a mouse.
> The sad truth is that the status quo for GUIs is absolutely terrible, and most were rushed out and not properly tested to check if they're really usable without a mouse.
This is the key point. No platform UI paradigm focuses on keyboard navigability and speed, all focus on mouse and visual effects for discoverability in a pursuit to dumb down the user experience enough to make it usable for everyone, breaking power users in the process (and increasingly also accessibility stacks).
Re: Stop Making TUIs
#284As 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?
Agreed. This is exactly what I want, ideally with components and libraries and panels and data shareable and extendable between applications.
The closest in spirit is Probably something like Dear ImGui[0] and the ecosystem of components and apps built with it, but it's not quite there for me. Something is missing.
Re: Stop Making TUIs
#285> Stop Making TUIs
No, I don't think I will :)
It's great for admin tools, alongside CLIs.
It's portable, it's fast, it's discoverable, it has zero bullshit effects, it's as secure as my shell, it's efficient.
And what is this point about agents making it easy to generate GUIs ? They are equally good (if not better) at generating TUIs using any of the great frameworks for this.
Re: Stop Making TUIs
#286As 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…
I have a question - I've briefly looked at the API, and it seems like a mostly general-purpose user interfance library. What do you think of replacing the 'render' part with something that's more like a generic UI? You could keep the UX the same, yet your app would look like a desktop app (or at least close to it). Trying to fit in the limitations of 80x25 text rendering is cool, but there's nothing in the underlying…
If you're redesigning a protocol layer, then I'd say you still want to target fixed size cells as the unit of rendering. It's just not the central abstraction like it is in the current terminal approach. Because you're one step above here, you have th ability to do better border handling. There's a lot a things you miss trying to force borders through a character set thing (e.g. missing characters depending on your font, missing ability to position borders naturally, interaction with background color, adjustment of size and space of rendered text due to interaction with unicode characters and fixed positioning) ...
But in general, going with a fresh new protocol allows you to do a bunch of things semantically that are currently done as pure graphical stuff and that's useful.
Re: Stop Making TUIs
#287TUIs allow you to have infinitely many running in tmux and also work over ssh so there is that.
Actual GUIs also work over the network, either as a web service rendered in the browser or a desktop app with a backend network connection.
Re: Stop Making TUIs
#288Earlier quoted context omitted.
> 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?
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…
There is not much difference between a TUI and a GUI once the premise is "let's start from scatch all other again for each applications". Sure then there is no guideline that comes between idea and implementation. But there is also no built-in accessibility, UX best-practices and many specificity of handling a vast experience of building something stable over a large period of time with many feedback from many different scenario.
Re: Stop Making TUIs
#289Earlier quoted context omitted.
What do you like about them? I disagree, but so many people seem to like them that I assume I'm missing something. The main one I've heard before is that they work nicely over SSH, but I assume there must be more?
I also like them so I can mention some things that spring to mind: - Some are very good tools that have no clear GUI superiors. Vim, Emacs, Mc for example. GUI wrappers over these don't make them better. - Efficient, meaning fast and limited in scope so you can learn the whole thing. - The muscle memory you develop is transferable to any new platform or OS you use. - Often free and OSS so they can't be taken away, ma…
Muscle memory and awful connectivity in remote places (well, not even that remote for me) is what so many GUI apps undervalue, and I don't think the author of the article has ever thought of or encountered this. I loved TUIs back in the '80s and '90s when convention was so consistent across applications that muscle memory transferred seamlessly. Plus one could use a mouse to select menu options or the keyboard (like the many Microsoft programming environments like QuickBASIC, QuickC, Microsoft C as well as competitor products like Turbo Pascal and many others).
The low bandwidth / high latency lossy link problem is still a major issue. Cell phone service is sufficiently shitty in the area I live in that I have to use mosh to get a usable remote connection many times a year. Mosh is also quite useful while travelling! Got a crappy connection on a train or airplane? No problem. I have so much muscle memory with the mutt email client that nothing else has ever come close. Where's the equivalent of mutt's limit command in Thunderbird?
Try getting a usable VNC session when your cell phone hot spot is hitting 2-30 second ping times (yes -- thirty seconds) with only a handful of packets getting through.
Version 2 of the Amiga's operating system did a great thing in version 2 of AmigaOS which explicitly spelled out what conventions to apply (see Amiga User Interface Style Guide at https://archive.org/details/amiga-user-interface-style-guide). Modern GUIs that have weird meaningless buttons are infuriating. Even moreso when they lack obvious keyboard shortcuts.
Re: Stop Making TUIs
#290Earlier quoted context omitted.
What you're comparing is really "keyboard-driven" via "mouse-drive". A GUI can be keyboard-driven and as fast as a TUI. The sad truth is that the status quo for GUIs is absolutely terrible, and most were rushed out and not properly tested to check if they're really usable without a mouse.
Yes, but GUIs are by default mouse driven, very rarely one can see a keyboard driven one (I haven't seen any). And TUIs are only keyboard driven. So the choice for speed if you don't need graphics is always - TUI (or CLI).
> And TUIs are only keyboard driven
Absolutely not.