Oh dear, the comments here are a bit disturbing and hilarious. The "Linux" mindset simply does not comprehend that proper UI's can still be made. Maybe that also includes the Windows mindset these days. Most of us macOS users never rejected TUI's, but we always had world class GUI's.
Stop Making TUIs
351–360 of 579 posts
Re: Stop Making TUIs
#352No, thanks. I don't want a mere "user" interface, I want a programmer's interface . I don't like the command line because I'm a "unix nerd", I like it because it lets me rapidly cook up little programs and execute them. Here's an example I just pulled out of my shell history: c=3afba1a; reset; laptop "virtdev ssh liblinux -- git -C liblinux format-patch -1 ${c} --stdout" | tee /dev/tty | termux-clipboard-set This hug…
From the article > CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is. You're also arguing for CLIs which are absolutely great. But TUIs provide none of the composability of CLIs nor the malleability of GUIs
If you use the terminal a lot then TUIs keep you there wo the need to manage yet a other window in the OS. For e.g. you can run nvim in another pane in tmux.
Re: Stop Making TUIs
#353No, thanks. I don't want a mere "user" interface, I want a programmer's interface . I don't like the command line because I'm a "unix nerd", I like it because it lets me rapidly cook up little programs and execute them. Here's an example I just pulled out of my shell history: c=3afba1a; reset; laptop "virtdev ssh liblinux -- git -C liblinux format-patch -1 ${c} --stdout" | tee /dev/tty | termux-clipboard-set This hug…
From the article > CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is. You're also arguing for CLIs which are absolutely great. But TUIs provide none of the composability of CLIs nor the malleability of GUIs
Maybe compatibility goes away a with TUIs. But portability, speed, remote access, and less resource usage are still key advantages.
Re: Stop Making TUIs
#354Sorry, no. I don't want to forward a whole desktop environment just because I want to use a small application I have written for myself. TUIs are much more portable, easier on eyes, can be information dense, and resistant to lassiez-faire UI library changes on platforms. They don't need GPUs to render, megabytes of RAM to run, great amounts of bandwidth to access from afar. I'll write a library for the functionality,…
TUIs also live where the rest of the interesting stuff happens, in the terninal. They don't force you to move to a different env
Re: Stop Making TUIs
#355Earlier 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).
A lot of GUIs can be muse driven.
The problem is discoverability. You need to go out of your way to learn shortcuts.
Re: Stop Making TUIs
#356Yes, stop making TUIs. Make GUIs in Terminals!
It’s ridiculous how far we have fallen behind the Terminal GUIs from the early 90ies. Look at the Turbo Pascal IDE and business apps built with it. Windows, window management, scrolling in windows, rich dialogs. Everything there. While many modern TUIs are just lists with numbers you can select. Everything is pretty rudimentary
I was missing a real terminal GUI library for some software I built. The rudimentary libraries did not work for me.
That‘s why I took Free Vision (the Turbo Vision derivative for Free Pascal) and ported it with the help of Claude Code over to modern Delphi, then modernised the object system and added lots of features and from there we ported it to go.
There are still lots of bugs and oversights (some caused by me not really knowing how original TV worked) that I fix as I go along using it for real projects.
https://github.com/oldwired/fv-delphi-modern https://github.com/oldwired/fv-go
Re: Stop Making TUIs
#357stop making your blog take 20% width on my 4k monitor
Re: Stop Making TUIs
#358Earlier 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…
That ubiquity is the reason for the limitations of terminals/TUIs discussed in grandparent. Those two are not separable: they’re everywhere precisely because they target the lowest, oldest common denominator (teletype console behavior assumptions from the 1960s).
I expanded on this point nearby: https://news.ycombinator.com/item?id=49400697
Re: Stop Making TUIs
#359TUIs work where I do.
I don't want to juggle another window unless I need to. Tmux gives me better ways of organizing my work than most display managers. Most of the useful things I do end up calling other shell commands, and it's nice having terminal right there. Ctrl-t / fg are also uniquely powerful.
UIs are also useful for information that is best represented in a UI. keep using those too.
You can bend each to be more similar to the other, and that's good too! Sometimes there is a good use case for that.
Re: Stop Making TUIs
#360Earlier quoted context omitted.
Opening more than one instance is the default, developers have to actively work to block it. At least on desktop.
Which desktop? It's not true for AppKit, SwiftUI, GTK, Qt, WinUI, or Electron, and I'm not sure what's left.
It's standard for Windows. Double click a .exe, and a new copy loads and runs. If it wants to quit because there's an existing instance running, the code has to arrange for that itself. (It's possible Qt does this for you by default. Depending on the app, this can simplify some things, sometimes! Maybe WinUI is the same.)
It looks like macOS Finder tries to make it difficult to run two copies of a .app simultaneously, so I imagine many programs don't check for this case, but this is Hacker News, so we can use our hacker skills to try and do what they don't want us to: find the exe inside the bundle and run it directly from Finder, or run it from the terminal using its path. (This works for me with Ptacek's mdv app. Two copies of it end up in the dock.)