7 ms·

CLIs (that read input from stdin and spit out results to stdout/stderr) are useful in an automation/data processing pipeline. But TUIs are a gimmick that should

CLIs (that read input from stdin and spit out results to stdout/stderr) are useful in an automation/data processing pipeline. But TUIs are a gimmick that should have been just GUIs. (And text selection is not a reason to resort to TUIs — it’s a reason to improve GUIs.) Unfortunately native GUI programming doesn’t have the coolness/geekiness factor of TUI apps… Edit: Looks like I should clarify – I'm not saying that people should stop creating TUIs right now: in the current landscape, TUIs do have advantages like being usable over ssh, text selection, a simpler programming model in most languages... but I'm arguing that these advantages aren't inherent to TUIs. We should aim to improve GUIs, not stuck in a interface from the 70s. Unfortunately I've seen too many people (including a big chunk of HN) that argue that TUIs are just inherently superior.

Arnavion 5y ago
I can make a TUI by just reading from stdin, writing to stdout, and some minimal parsing and emitting of VT codes that have mostly not changed in a few decades. To make a GUI I have to pull in megabytes of libraries, learn their API, then update them every time they release a new version that will likely have breaking changes. They'll also have questionable bindings outside of one or two "first-class" languages, so reading docs and investigating why something isn't working is harder. I'll stick with TUIs, thanks.
- hahajk 5y ago
  Web interfaces are the GUI equivalent of the simple, timeless tty interface. My 10 year old router still renders html just fine on modern Chrome.
  - Arnavion 5y ago
    Yes, but at the cost of needing to run a browser. In this modern era of everyone fetishizing single-instance applications, a browser crash caused by one tab would mean I lose not only all my open websites but also all these "apps". I have to `pkill -9` firefox once every few days because of bugs; a few months ago it used to break the clipboard until it was restarted, these days it freezes when dragging tabs around in the tab bar, tomorrow I'm sure it'll be some new bug... I'm glad I don't lose my editor / IDE / chat clients / monitoring dashboards when this happens.
- likeclockwork 5y ago
  And after all that work you can't even use your GUI over SSH.
  - Izkata 5y ago
    Sure, with X11 forwarding.
    - saulpw 5y ago
      You can't use your GUI over 9600 bps serial port (yes this is sometimes still relevant).
      - wutbrodo 5y ago
        Or even just a shitty wifi connection in an underdeveloped region or area.
    - II2II 5y ago
      The major desktop and workstation operating systems usually have an SSH client installed by default. The same cannot be said for X11. It is easy enough to use X11 on a mobile device. You may be able to get an X client for a mobile device, but I wouldn't want to use it. (Not to mention that some X11 software doesn't seem to work across the network these days, which causes me no end of frustration since RDP is usually fantastic. Not to mention the bandwidth requirements of graphical sessions, which is a concern over mobile networks.)
      - IshKebab 5y ago
        Windows doesn't have an SSH client installed by default. But I agree with your point - setting up SSH is way easier than X11 and X11 doesn't even work that well over the internet. VNC would be a more reasonable answer but that is a pain to set up server-side on Linux and isn't very good. Really NX4 is the answer but it costs an absolute fortune.
  - deleted 5y ago
    [deleted]
- pcr910303 5y ago
  That's an argument for making GUI libraries more ergonomic, not to keep making TUIs. And TUIs made by "just printing VT codes" will break when you resize the terminal, change the font size, or more.
  - zozbot234 5y ago
    TUI's can deal with changes in terminal geometry, generally by redrawing. It even works in a telnet/ssh connection, the remote host gets sent that information and uses it accordingly.
    - pcr910303 5y ago
      Yes, it does. But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program), and you lose the aspect of 'creating TUIs are just printing VT codes'.
      - gnubison 5y ago
        Redrawing a TUI from scratch is usually trivial. Certainly far simpler than your average GUI.
      - marssaxman 5y ago
        It's far less complexity, even still, and it has not changed much for decades. A TUI program working today will likely continue to work for decades more. If you don't care about glitz and just want to write something useful, that's a substantial draw.
      - RobertMiller 5y ago
        > But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program) No way dude. All you need to do is catch SIGWINCH and then ioctl/TIOCGWINSZ to get the new size. Back when I was into roguelike development, responding to the terminal resizing took scarcely more than a half dozen lines of C. I wish I knew of a GUI system this simple.
- jrm4 5y ago
  Right, I don't think you and OP are in conflict at all. Basically, GUIs presently suck. The average perfomance differences between TUI's and GUI's point directly to the fact that GUIs are very very bloated. There's no reason that a GUI shouldn't be as performant as a TUI, given the relative minimum it ought to take to convert one to another. A little vector here and raster support there should mostly take care of it.
- GeneralMaximus 5y ago
  Then you make your software unusable for everyone who needs to use languages other than English. For example, I can't reliably type Devanagari (the script used by Hindi, Marathi, Nepali, and a bunch of other South Asian languages) into any terminal on any operating system. You also make your software unusable for people who use assistive software. TUIs are not accessible by default, GUIs can be with only a tiny bit of effort. TUIs are perfectly fine for internal tooling, but any piece of software intended for general distribution should ship with a proper GUI. Even a basic Electron UI beats TUI in terms of accessibility and internationalization support.
  - Arnavion 5y ago
    My terminal (foot) supports IME just fine, using the same protocol that a GUI application uses.
    - GeneralMaximus 5y ago
      It's not just about the IME. I'm on macOS, where it's possible to type Devanagari/Gurumukhi into both iTerm and Terminal.app without any issues. However, neither of the emulators can render the typed text correctly. I tried typing "नमस्ते" into both just now, and they both broke in different ways. Here's iTerm failing to render a half स: https://imgur.com/a/vg1i4aB https://imgur.com/a/vg1i4aB Here's Terminal.app messing up how the quotation mark gets rendered: https://imgur.com/a/B5zd85V https://imgur.com/a/B5zd85V Can foot handle this case? What about GNOME Terminal, Konsole, and Windows Terminal? If I can't reliably read Hindi text on the commonly used terminal emulators on all three major operating systems, then from my perspective a TUI app is worse in every way compared to a native GUI app or even an Electron app.
      - dotancohen 5y ago
        How is this, in KDE's Konsole? https://imgur.com/a/xYjUQRv https://imgur.com/a/xYjUQRv
        mnsc 5y ago
btrettel 5y ago
> TUIs are a gimmick that should have been just GUIs. I mostly agree. I use Midnight Commander a lot but I'd prefer a basically identical GUI version with the same keys. None of the Linux GUI orthodox file managers I looked at were comparable, though I didn't do a comprehensive search. (Edit: There are tons of GUI orthodox file managers for Linux. I was wrong.) The main advantage of a TUI to me is that it is available over SSH more easily. X forwarding exists but I never recall it being particularly responsive. As another commenter says, TUIs also have advantages in terms of coding.
- zozbot234 5y ago
  Didn't Midnight Commander come with a GTK+ based graphical version back in the day? It was the first file manager component in GNOME before Nautilus replaced it.
  - deleted 5y ago
    [deleted]
- kevin_thibedeau 5y ago
  X forwarding works great with traditional apps using oldschool toolkits without any bitmap chrome and all text rendering deferred to the server.
agumonkey 5y ago
GUI's can be too slow and too heavy. Good TUI can be hyper fast user wise.
zozbot234 5y ago
TUI's are very useful over ssh, where existing ways of remoting GUI's have way too much overhead.
humanwhosits 5y ago
TUIs are GUIs, just different tech. Many times you don't have graphical access to the machine. As an example, `htop` is very useful when I don't have access to `gnome-system-monitor`.
flukus 5y ago
> CLIs (that read input from stdin and spit out results to stdout/stderr) are useful in an automation/data processing pipeline. TUI's and GUI's can both be used in the middle of a pipe when things require some manual fiddling, Git commit would be an example of this, opening vim to edit the commit message. Here's an example (https://stackoverflow.com/questions/8371877/ncurses-and-linux-pipeline/44884859#44884859 https://stackoverflow.com/questions/8371877/ncurses-and-linu...) of how you could create an ncurses TUI but still output to stdout. Dmenu (https://tools.suckless.org/dmenu/ https://tools.suckless.org/dmenu/) is a good example of a gui program that fits comfortably in a pipeline.
II2II 5y ago
One of the nice things about TUIs is the removal of visual clutter and other forms of distraction. I also recall an article a while back about Emacs and screen readers. Since everything has to be representable as text, rather than accessibility being an afterthought, it was usable with screen readers. I imagine something similar can be said for those who need better contrast or large text, since terminal colour schemes can be defined by the user and software has to handle variable terminal sizes.
rgoulter 5y ago
Ideally! In practice, for use cases where you're spelunking through different directories and running different commands: you're going to have an easier time either staying in a terminal (where opening a GUI to perform a task is awkward), or an easier time sticking with a GUI (where opening a terminal to run a command is awkward). Currently, TUI provides many of the benefits of a GUI, without having to leave the terminal.
gandalfff 5y ago
Couldn't agree more. A good GUI beats a TUI any day. They have the potential to be far more intuitive as well as more aesthetically appealing. Not to mention that for some of us, a GUI gives far greater confidence than a TUI. For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes. I do think GUIs can learn a few tricks from TUIs. TUIs are often more responsive and usually provide better keyboard driven workflows. Ultimately my preference for GUIs probably reflects what I'm used to. To paraphrase Jef Raskin, there are no intuitive UIs, only familiar ones.
- anthk 5y ago
  >For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes. cfdisk, cgdisk. Maybe you are afraid of parted/fdisk. Then you are right. But well, fdisk and such are a bit "nightmarish". I had more luck using OpenBSD's disklabel to slice up it's own partitions. And the GPT editor from OpenBSD (I can't remember it's name) was pretty simple to use and preview even on text mode. You can have both good and bad CLI/TUI's, and even horrendous GUI's, such as the Red Hat installer.
pjmlp 5y ago
Having started programming in a time where all we had were TUIs and GUIs were only accessible in expensive workstations (first computer, a Timex 2068), I also don't get this adoration for TUI and CLI. They are a reflection of a time when I would like to have more and it was out of reach. We used them because it was everything we had access to, that is all.
BeetleB 5y ago
One reason GUIs aren't as cool as TUIs is ... people don't want them to be. Growing up with TUIs, I was quite surprised how often people refuse to use a program because it doesn't conform to the "native" look and feel. I've found plenty of people who'll happily use htop in the terminal, but then complain when a GUI app doesn't respect some tiny aspect of look and feel. Even things like the placement of "Options" or "Preferences" in the "wrong" menu causes them ire. For whatever reason, people just seem to expect different things from GUIs.
gjulianm 5y ago
TUIs definitely have their place. For starters, a lot of terminal applications really don't need anything from a GUI. And GUIs carry some weight that will not be shed: - The required libraries you need to install for them. A docker image with TUI tools can be light, with GUIs it will be heavy. - Usability over SSH is definitely a TUI inherent advantage. X forwarding is an absolute mess, and even if someone tried to improve it probably would still be a mess. Executing code in a remote machine and sending the graphics to another system (possibly with different graphical interface or even operating system) is never going to be as responsive or integrated.
tartoran 5y ago
TUIs are designed to be used without a mouse and are ligtning fast. Information is condensed due to limitations to text only. By the time you open a GUI you lose or corrupt your thought process when bombarded with more visual information than the little change you wanted to make. TUIs are great for a quick in and out while GUIs are great to linger there for a while. And do some click click clicking.
wutbrodo 5y ago
> I'm arguing that these advantages aren't inherent to TUIs. How do you use a GUI app inline inside a screen session? And I mean _use_ it inside, not launch a floating GUI window that's disconnected from your entire workflow. There are advantages to remaining inside the terminal, for those who are comfortable with the terminal.

Arnavion 5y ago

I can make a TUI by just reading from stdin, writing to stdout, and some minimal parsing and emitting of VT codes that have mostly not changed in a few decades. To make a GUI I have to pull in megabytes of libraries, learn their API, then update them every time they release a new version that will likely have breaking changes. They'll also have questionable bindings outside of one or two "first-class" languages, so reading docs and investigating why something isn't working is harder. I'll stick with TUIs, thanks.

hahajk 5y ago
Web interfaces are the GUI equivalent of the simple, timeless tty interface. My 10 year old router still renders html just fine on modern Chrome.
- Arnavion 5y ago
  Yes, but at the cost of needing to run a browser. In this modern era of everyone fetishizing single-instance applications, a browser crash caused by one tab would mean I lose not only all my open websites but also all these "apps". I have to `pkill -9` firefox once every few days because of bugs; a few months ago it used to break the clipboard until it was restarted, these days it freezes when dragging tabs around in the tab bar, tomorrow I'm sure it'll be some new bug... I'm glad I don't lose my editor / IDE / chat clients / monitoring dashboards when this happens.
likeclockwork 5y ago
And after all that work you can't even use your GUI over SSH.
- Izkata 5y ago
  Sure, with X11 forwarding.
  - saulpw 5y ago
    You can't use your GUI over 9600 bps serial port (yes this is sometimes still relevant).
    - wutbrodo 5y ago
      Or even just a shitty wifi connection in an underdeveloped region or area.
  - II2II 5y ago
    The major desktop and workstation operating systems usually have an SSH client installed by default. The same cannot be said for X11. It is easy enough to use X11 on a mobile device. You may be able to get an X client for a mobile device, but I wouldn't want to use it. (Not to mention that some X11 software doesn't seem to work across the network these days, which causes me no end of frustration since RDP is usually fantastic. Not to mention the bandwidth requirements of graphical sessions, which is a concern over mobile networks.)
    - IshKebab 5y ago
      Windows doesn't have an SSH client installed by default. But I agree with your point - setting up SSH is way easier than X11 and X11 doesn't even work that well over the internet. VNC would be a more reasonable answer but that is a pain to set up server-side on Linux and isn't very good. Really NX4 is the answer but it costs an absolute fortune.
- deleted 5y ago
  [deleted]
pcr910303 5y ago
That's an argument for making GUI libraries more ergonomic, not to keep making TUIs. And TUIs made by "just printing VT codes" will break when you resize the terminal, change the font size, or more.
- zozbot234 5y ago
  TUI's can deal with changes in terminal geometry, generally by redrawing. It even works in a telnet/ssh connection, the remote host gets sent that information and uses it accordingly.
  - pcr910303 5y ago
    Yes, it does. But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program), and you lose the aspect of 'creating TUIs are just printing VT codes'.
    - gnubison 5y ago
      Redrawing a TUI from scratch is usually trivial. Certainly far simpler than your average GUI.
    - marssaxman 5y ago
      It's far less complexity, even still, and it has not changed much for decades. A TUI program working today will likely continue to work for decades more. If you don't care about glitz and just want to write something useful, that's a substantial draw.
    - RobertMiller 5y ago
      > But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program) No way dude. All you need to do is catch SIGWINCH and then ioctl/TIOCGWINSZ to get the new size. Back when I was into roguelike development, responding to the terminal resizing took scarcely more than a half dozen lines of C. I wish I knew of a GUI system this simple.
jrm4 5y ago
Right, I don't think you and OP are in conflict at all. Basically, GUIs presently suck. The average perfomance differences between TUI's and GUI's point directly to the fact that GUIs are very very bloated. There's no reason that a GUI shouldn't be as performant as a TUI, given the relative minimum it ought to take to convert one to another. A little vector here and raster support there should mostly take care of it.
GeneralMaximus 5y ago
Then you make your software unusable for everyone who needs to use languages other than English. For example, I can't reliably type Devanagari (the script used by Hindi, Marathi, Nepali, and a bunch of other South Asian languages) into any terminal on any operating system. You also make your software unusable for people who use assistive software. TUIs are not accessible by default, GUIs can be with only a tiny bit of effort. TUIs are perfectly fine for internal tooling, but any piece of software intended for general distribution should ship with a proper GUI. Even a basic Electron UI beats TUI in terms of accessibility and internationalization support.
- Arnavion 5y ago
  My terminal (foot) supports IME just fine, using the same protocol that a GUI application uses.
  - GeneralMaximus 5y ago
    It's not just about the IME. I'm on macOS, where it's possible to type Devanagari/Gurumukhi into both iTerm and Terminal.app without any issues. However, neither of the emulators can render the typed text correctly. I tried typing "नमस्ते" into both just now, and they both broke in different ways. Here's iTerm failing to render a half स: https://imgur.com/a/vg1i4aB https://imgur.com/a/vg1i4aB Here's Terminal.app messing up how the quotation mark gets rendered: https://imgur.com/a/B5zd85V https://imgur.com/a/B5zd85V Can foot handle this case? What about GNOME Terminal, Konsole, and Windows Terminal? If I can't reliably read Hindi text on the commonly used terminal emulators on all three major operating systems, then from my perspective a TUI app is worse in every way compared to a native GUI app or even an Electron app.
    - dotancohen 5y ago
      How is this, in KDE's Konsole? https://imgur.com/a/xYjUQRv https://imgur.com/a/xYjUQRv
      - mnsc 5y ago

btrettel 5y ago

> TUIs are a gimmick that should have been just GUIs. I mostly agree. I use Midnight Commander a lot but I'd prefer a basically identical GUI version with the same keys. None of the Linux GUI orthodox file managers I looked at were comparable, though I didn't do a comprehensive search. (Edit: There are tons of GUI orthodox file managers for Linux. I was wrong.) The main advantage of a TUI to me is that it is available over SSH more easily. X forwarding exists but I never recall it being particularly responsive. As another commenter says, TUIs also have advantages in terms of coding.

zozbot234 5y ago
Didn't Midnight Commander come with a GTK+ based graphical version back in the day? It was the first file manager component in GNOME before Nautilus replaced it.
- deleted 5y ago
  [deleted]
kevin_thibedeau 5y ago
X forwarding works great with traditional apps using oldschool toolkits without any bitmap chrome and all text rendering deferred to the server.

agumonkey 5y ago

GUI's can be too slow and too heavy. Good TUI can be hyper fast user wise.

zozbot234 5y ago

TUI's are very useful over ssh, where existing ways of remoting GUI's have way too much overhead.

humanwhosits 5y ago

TUIs are GUIs, just different tech. Many times you don't have graphical access to the machine. As an example, `htop` is very useful when I don't have access to `gnome-system-monitor`.

flukus 5y ago

> CLIs (that read input from stdin and spit out results to stdout/stderr) are useful in an automation/data processing pipeline. TUI's and GUI's can both be used in the middle of a pipe when things require some manual fiddling, Git commit would be an example of this, opening vim to edit the commit message. Here's an example (https://stackoverflow.com/questions/8371877/ncurses-and-linux-pipeline/44884859#44884859 https://stackoverflow.com/questions/8371877/ncurses-and-linu...) of how you could create an ncurses TUI but still output to stdout. Dmenu (https://tools.suckless.org/dmenu/ https://tools.suckless.org/dmenu/) is a good example of a gui program that fits comfortably in a pipeline.

II2II 5y ago

One of the nice things about TUIs is the removal of visual clutter and other forms of distraction. I also recall an article a while back about Emacs and screen readers. Since everything has to be representable as text, rather than accessibility being an afterthought, it was usable with screen readers. I imagine something similar can be said for those who need better contrast or large text, since terminal colour schemes can be defined by the user and software has to handle variable terminal sizes.

rgoulter 5y ago

Ideally! In practice, for use cases where you're spelunking through different directories and running different commands: you're going to have an easier time either staying in a terminal (where opening a GUI to perform a task is awkward), or an easier time sticking with a GUI (where opening a terminal to run a command is awkward). Currently, TUI provides many of the benefits of a GUI, without having to leave the terminal.

gandalfff 5y ago

Couldn't agree more. A good GUI beats a TUI any day. They have the potential to be far more intuitive as well as more aesthetically appealing. Not to mention that for some of us, a GUI gives far greater confidence than a TUI. For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes. I do think GUIs can learn a few tricks from TUIs. TUIs are often more responsive and usually provide better keyboard driven workflows. Ultimately my preference for GUIs probably reflects what I'm used to. To paraphrase Jef Raskin, there are no intuitive UIs, only familiar ones.

anthk 5y ago
>For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes. cfdisk, cgdisk. Maybe you are afraid of parted/fdisk. Then you are right. But well, fdisk and such are a bit "nightmarish". I had more luck using OpenBSD's disklabel to slice up it's own partitions. And the GPT editor from OpenBSD (I can't remember it's name) was pretty simple to use and preview even on text mode. You can have both good and bad CLI/TUI's, and even horrendous GUI's, such as the Red Hat installer.

pjmlp 5y ago

Having started programming in a time where all we had were TUIs and GUIs were only accessible in expensive workstations (first computer, a Timex 2068), I also don't get this adoration for TUI and CLI. They are a reflection of a time when I would like to have more and it was out of reach. We used them because it was everything we had access to, that is all.

BeetleB 5y ago

One reason GUIs aren't as cool as TUIs is ... people don't want them to be. Growing up with TUIs, I was quite surprised how often people refuse to use a program because it doesn't conform to the "native" look and feel. I've found plenty of people who'll happily use htop in the terminal, but then complain when a GUI app doesn't respect some tiny aspect of look and feel. Even things like the placement of "Options" or "Preferences" in the "wrong" menu causes them ire. For whatever reason, people just seem to expect different things from GUIs.

gjulianm 5y ago

TUIs definitely have their place. For starters, a lot of terminal applications really don't need anything from a GUI. And GUIs carry some weight that will not be shed: - The required libraries you need to install for them. A docker image with TUI tools can be light, with GUIs it will be heavy. - Usability over SSH is definitely a TUI inherent advantage. X forwarding is an absolute mess, and even if someone tried to improve it probably would still be a mess. Executing code in a remote machine and sending the graphics to another system (possibly with different graphical interface or even operating system) is never going to be as responsive or integrated.

tartoran 5y ago

TUIs are designed to be used without a mouse and are ligtning fast. Information is condensed due to limitations to text only. By the time you open a GUI you lose or corrupt your thought process when bombarded with more visual information than the little change you wanted to make. TUIs are great for a quick in and out while GUIs are great to linger there for a while. And do some click click clicking.

wutbrodo 5y ago

> I'm arguing that these advantages aren't inherent to TUIs. How do you use a GUI app inline inside a screen session? And I mean _use_ it inside, not launch a floating GUI window that's disconnected from your entire workflow. There are advantages to remaining inside the terminal, for those who are comfortable with the terminal.