CLI is trending amongst dev's again, and we should take a lesson by htop how to design a good user interface.
CLI is trending amongst dev's again, and we should take a lesson by htop how to design a good user interface.
Part of why the shell is gaining is that UIs are invariably becoming less efficient with rampant use of React and node for native apps.
I did not say node is slow.
I don't know if that's as true as "GUIs are now unfashionable to devs". It is hard to blame them since GUIs have regressed so significantly ever since the iPhone.
Did it ever stopped being useful?
I just hope it doesn't swing back too far the other way as it has before (I've been around long enough to have seen the cycle previously!). I'm a big fan for command line, scriptable, tools and plain text pipe-able output, and have been since being introduced to pipes & redirection all those decades ago, but we need to avoid the holier-than-thou thing that seems to develop when our old timer ways get the lime-light for a while. It only serves to put people off learning that they are great tools for many jobs and definitively the right ones for a some.
Check out newsboat, nmtui, ranger, w3m, mikmod, slack-term/weechat/irssi/finch, sc, mps-youtube, micro (text editor) just to name a few... Seems to be very popular among people who use tiling window managers.
In fact, with a good terminal multiplexer, mpv and fbv, all you need X for is stuff like web apps and Gimp.
Today, even some of those tools are embracing CLIs.
htop has a GUI, not a CLI. Some people call it a "TUI" but in terms of UX and program architecture it's a lot closer to a GUI than a CLI.
They do different things differently, but they achieve great results in their own ways.
The mc file manager or ranger more than stands the comparison against graphical file managers.
In an ideal world the concept of TUI would not exist.
A pathological example for me would be gvim. I tried using it for a while but I kept running into weird performance issues and general lagginess. Meanwhile from a terminal it Just Works. So I don't bother with it anymore, I always run Vim from a terminal and I never looked back.
In general I find that the terminal imposes two generally good constraints to application makers: everything must exist within a single window and mouse interaction is very limited (and not supported everywhere) so it's important that everything must be achievable with keyboard inputs.
These constraints disincentivize pathological mouse-driven "click click" pop up dialog fests which are the bane of my existence.
I have a hard time imagining that ideal world. TUIs have their own advantages that can't really be met with GUIs without restricting them and giving up some features of GUIs.
1. Being able to use it through SSH and other sorts of connections like a serial connection through the headphone jack on the PinePhone.
2. All text can be copy-pasted, guaranteed. Devs don't have the option to prevent that.
3. Its use is very simple to automate.
3.1. Don't need random sleeps while the interface is updated, just read and write to the terminal and let those calls hang if they need to.
3.2. No need to guess pixel coordinates of inputs to emulate clicks on them because the interface wasn't thought for keyboard use.
3.3. Sometimes you can even encode interactions in a stream of bytes that you can then paste into the terminal to execute on the TUI.
3.4. It's very simple for a script to pull text data from a TUI, but it's near impossible to pull it from a graphical window.
4. Terminal features like rectangular selection or keyboard-navigated copy-paste can be used for all TUIs.
5. Encourages more efficient use of screen real-estate.
6. Simpler themes, controlled by terminal settings. Simple to set the use of favorite font for everything.
7. More consistent look across TUIs because of terminal restrictiveness.
8. Can call a subprocess to take control of the terminal to do something and just come back when it finishes. This allows for simple ad-hoc multitasking through the terminal connection without special support of something like termux which requires foresight.
9. The fact that the application doesn't need to handle frivolous things like re-rendering after the window is moved or handle every mouse movement over it, makes figuring out what it actually is doing that matters quite simpler. I'm referring to the output of strace. It's largely more readable on TUIs than GUIs because TUIs don't need to do the frivolous things GUIs do.
TUI also tends to have a certain aesthetic. I cut my teeth on computers where it was common for the UI to be made from ASCII text.
Another example is 'apt-get' vs aptitude. The earlier is inherently scriptable. The latter needs you to start the program, input a few keys, exit.
fdisk is another terminal program that's not command line.
no, ncurses is an implementation kit for screen-oriented TUIs. CLI, TUI, GUI are all separate things..