Why would I prefer Terminal programs over GUI

Introduction

I – like some other people – prefer applications that run in a Terminal Emulator (e.g. urxvt) over ones that provide a GUI using a GUI toolkit.

While it has often been argued that using commandline applications has advantages over graphical user interfaces (GUIs) – mostly that commands can be scripted – this does not in the same sense apply to the typical ncurses/mainframe forms of Terminal User Interfaces (TUIs).

While I like commandline programs well enough, I also prefer TUIs over GUIs most of the time. Could there be any reason for this beyond personal taste?

Partial Reasons

Some people claim that it is faster to use TUIs. While there are inefficient and slow GUI programs out there, this problem is not inherent to GUIs although probably more prevalent there.

No animations: TUI programs use very limited animations. Actually, the only non-toy example that I can think of is progress bars and turning wheels where something computes. OTOH, GUI programs often have some more advanced animations. Most of the time it is possible to configure them at the GUI toolkit level hence this should not be the primary reason for chosing TUI over GUI?

Some people claim that TUIs allow you to perform all operations with the keyboard which could also be an advantage in speed. However, some GUI programs have customizable keyboard shortcuts, too and hence allow for efficient keyboard usage. Chosing TUIs is an almost surefire way to avoid programs that heavily rely on mouse control. If one works with the keyboard most of the time already, it may pay off to avoid the change between keyboard and mouse. Some GUI (?) people optimize this by using tenkeyless (TKL) keyboards which reduces the distance between mouse and keyboard to allow for faster switching between the two input devices. Going for TUIs is thus not the only way to achieve a more efficient interaction with the computer.

Some people claim that TUIs are available remotely more easily compared to GUI programs. I think that for Linux, there is some merit in this argument. While there is X11 forwarding, its performance can be bad in practical unstable link scenarios. Windows’ RDP does a much better job at transporting a GUI experience remotely, though. It hence does not seem that remoting would be limited to TUIs. In practice it is sometimes more feasible to install a TUI program on a remote machine than to do the respective GUI equivalent. Think of installing mc on a server (one package, a few kibibytes) vs. installing thunar on a server (pulls in the entire GTK framework as a dependency and probably indirectly recommends daemons that one would not want to have on a server). Similar considerations hold for leaving a remotely running program open: You could easily deploy a statically-linked tmux to the remote system and keep it open there whereas running a VNC server on the remote system is much heavier and could be complex to deploy if administrative privileges are not available on the remote system.

My Reasons

No symbols: TUI programs use symbols in place of text very sparingly whereas for GUI programs it is common to encode large parts of the interface in little icons and other symbols. I find it easier to digest the text over the symbols and thus prefer TUIs.

No touch optimization (or IOW: Efficient screen space usage): Some modern GUI programs assign overly large parts of the screen space to UI functions leaving less space to the actual data of interest. Given that I do not normally use touch interfaces, I prefer the more cramped visuals of old-style GUI applications (Think: Windows 2000 and before) in the GUI world. The TUIs I have used so far are all touch-unaware and hence do not make the UI elements any bigger than needed. This often results in a more efficient use of screen space. Examples:

• My preferred text editor VIM dedicates only two lines of screen space to the UI, the remainder is taken by the file being edited.
• My preferred e-mail client cone takes four lines of screen space for the TUI which is still far less than the typical GUI mail client or web browser: Firefox, with menu, tabs and URL bar takes six lines of space for these elements. In TUI world, four would possibly enough, e.g. one for the menu, one for the tabs and one for the URL and maybe one as a separator.
• My preferred file manager vifm uses three lines for its GUI. The lightweight GUI file manager Thunar takes five lines in comparison.

Almost no responsive design: Modern GUI applications (websites and others) try to be overly clever regarding the screen space usage: They are already aware that GUI can take too much space and hence change the layout with the intention to show an accepatble amount of data even in the presence of smaller window sizes. In practice this leads to important GUI elements becoming hidden behind “hamburger” menus upon window resizes. This effect is especially problematic with tiling window managers because there, very small windows can naturally occur. In TUI applications, the behaviour is often more predictable: If there is too little space, the respective element gets cut. Functionality stays the same which means it remains possible to trigger the element of interest “blindly”. If one is familiar with the TUI, it saves from enlarging the window for just triggering this one function that one knows how to trigger anyways. All programs have limits if the windows get very small, but for GUI programs the problematic point is often reached earlier.

Integration: Most of my work is console-based anyways. Many TUI programs allow switching between the TUI and console easily. E.g. one can start a vim inside any already running console and one can even start a shell inside many TUI programs – :sh in VIM for instance. GUI programs in contrast do not integrate well in this regard. In my GUI times, Open Terminal Here was my most used feature of a GUI file manager. It is worth noting that this option is not available by default in all GUI file managers making them combersome to work with for my use cases.

Another aspect of integration is that with Terminal programs, all the visual details like font family, font size and colors are restricted and enforced by the Terminal emulator. All my terminal windows come with 16 (always equal) colors, Terminus and 18 px character height. All my TUI applications run with dark background by default whereas Dark Mode in GUIs is getting some traction but is not universally available yet. Independently of the TUI program that is running this results in a readable interface. In GUI programs, some fonts are always of different size. Notable offenders are tool tips or status lines that sometimes have much smaller fonts compared to the default. This makes them hard to read. If I were to increase the overall size of the GUI scaling this would make some other parts of the GUI unnecessary big. Having one consistent font size for everything like in the TUI works best for me. If something has to be highlighted there is still bold print and colors available. Also, having a limited choice of colors naturally avoids most of the low contrast issues from GUI programs. For TUI programs it is very uncommon to deviate from sane color choices. I have never encountered a TUI so far that had an intentional “gray on white” color scheme whereas this seems to be common on some websites and in some GUI programs. Unlike in the GUI world, where it is common to have multiple “frameworks” (QT, GTK, …) that one needs to configure separately to achieve consistent visuals, with TUIs it is all dictated by the terminal emulator. If I want to increase the font size, I have to edit exactly one file and all TUIs (even those running remotely!) will pick it up as soon as I start them in a newly opened Terminal Emulator.

Conclusion

It seems my only convincing argument for TUIs is Integration. I conclude that my reason for preferring TUIs is simply that I am using the terminal a lot already so it pays off in various regards to try staing “home” (in the terminal, on the keyboard) as much as possible.

I believe that this is not directly leading to “more productivity” or anything of that sorts. From my point of view, it seems to be largely a “better” feeling and hence in the end really a matter of taste. YMMV.