I generally agree but it depends on the application and the computer purpose / input you will most use.
Like… it doesn’t make much sense to have a CLI/TUI for an image editor… if you start using things like sixel you are essentially building a GUI that runs in a terminal, not a TUI. The same happens with videogames, video players and related entertainment applications.
But like I said, I do generally agree. I’d even argue that when possible, GUIs should just be frontends that ultimately just call the corresponding CLI programs with the appropriate parameters, avoiding duplication.
GUIs just being front-ends for a CLI tool is a horrible idea. This is why most git GUIs fail so terribly. I have seen too many of those where all the buttons were just replacements for CLI calls. If it is just a front-end for a CLI, then why the heck not just use the CLI?
A good git GUI has not been designed to just wrap the CLI. Instead, it works with the structure of git (commits, branches, tags, etc), and builds around those from the ground up. Only once the functionality has been designed should the question arise: What CLI commands do we need to implement this?
In general, I agree that you can always use the CLI raw, but a frontend is a lot more friendly for many. It’s the reason some people prefer TUI over CLI as well (some people really like lazygit and lazydocker which are just frontends wrapping git and docker CLI calls and presenting it in a TUI). A TUI/GUI can structure information in panels, it can be more context-sensitive and it can help provide visual representations of the operation.
Also, wrapping CLI commands (whether through a GUI or a TUI) means the wrapper can automatically combine the commands in whichever way it’s best for a particular goal, or more conveniently set up batch processing… it’s helpful for people who don’t like having to make their own scripts, or craft long oneliners.
Plus: lets say you have your computer hooked to your TV and don’t have space for a keyboard (but can use a small wireless mouse on the arm of your couch), a GUI wrapper that allows you to perform operations with just a mouse can be very convenient.
I don’t know what kind of GUIs are you imagining, but I’ve hardly ever seen 1-to-1 recreations to a single individual command (unless that command is extremely complex or a graphical representation would be actually useful).
Some examples:
Gparted creates a job list of terminal commands for the disk manipulation, but it presents a graphical representation of the disks before you actually commit to executing the commands internally, so you can see what would be the result of the changes in the GUI side before actually pressing the button that actually executes parted, fdisk, mkfs, resize2fs, etc. (they do wrap the commands when it comes to executing the changes), without you needing to go through the steps and specific syntax of each of them on your own.
There are wrappers to ffmpeg for video editing or transcoding that some people find convenient for discoverability of the options available and/or to have a limited list of presets / sanitized options for those who don’t want to bother creating their own scripts. Sometimes also showing video previews for the graphical representation (useful when the operation is about cropping the image, or picking the exact millisecond where to cut). An example is LosslessCut, they keep a log of the ffmpeg calls… or maybe Shutter Encoder (press Alt+C to see the console commands).
In Synaptic, the GUI package manager, pressing “Apply” calls the appropriate APT commands as a CLI app inside a VTE with the selection of the packages you have decided to add/remove/update, which you have previously selected in the listing that is generated from the GUI view of the app. Some people like having a graphical detailed listing which might be useful for conveniently browsing packages and seeing their detailed description, while still you get the raw information and accurate log from the installation that you would get when you are just using the CLI.
I generally agree but it depends on the application and the computer purpose / input you will most use.
Like… it doesn’t make much sense to have a CLI/TUI for an image editor… if you start using things like sixel you are essentially building a GUI that runs in a terminal, not a TUI. The same happens with videogames, video players and related entertainment applications.
But like I said, I do generally agree. I’d even argue that when possible, GUIs should just be frontends that ultimately just call the corresponding CLI programs with the appropriate parameters, avoiding duplication.
Exactly. I’m on the exact same boat, the blog post is the proof! :D
GUIs just being front-ends for a CLI tool is a horrible idea. This is why most git GUIs fail so terribly. I have seen too many of those where all the buttons were just replacements for CLI calls. If it is just a front-end for a CLI, then why the heck not just use the CLI?
A good git GUI has not been designed to just wrap the CLI. Instead, it works with the structure of git (commits, branches, tags, etc), and builds around those from the ground up. Only once the functionality has been designed should the question arise: What CLI commands do we need to implement this?
In general, I agree that you can always use the CLI raw, but a frontend is a lot more friendly for many. It’s the reason some people prefer TUI over CLI as well (some people really like
lazygitandlazydockerwhich are just frontends wrappinggitanddockerCLI calls and presenting it in a TUI). A TUI/GUI can structure information in panels, it can be more context-sensitive and it can help provide visual representations of the operation.Also, wrapping CLI commands (whether through a GUI or a TUI) means the wrapper can automatically combine the commands in whichever way it’s best for a particular goal, or more conveniently set up batch processing… it’s helpful for people who don’t like having to make their own scripts, or craft long oneliners.
Plus: lets say you have your computer hooked to your TV and don’t have space for a keyboard (but can use a small wireless mouse on the arm of your couch), a GUI wrapper that allows you to perform operations with just a mouse can be very convenient.
I don’t know what kind of GUIs are you imagining, but I’ve hardly ever seen 1-to-1 recreations to a single individual command (unless that command is extremely complex or a graphical representation would be actually useful).
Some examples:
Gparted creates a job list of terminal commands for the disk manipulation, but it presents a graphical representation of the disks before you actually commit to executing the commands internally, so you can see what would be the result of the changes in the GUI side before actually pressing the button that actually executes
parted,fdisk,mkfs,resize2fs, etc. (they do wrap the commands when it comes to executing the changes), without you needing to go through the steps and specific syntax of each of them on your own.There are wrappers to
ffmpegfor video editing or transcoding that some people find convenient for discoverability of the options available and/or to have a limited list of presets / sanitized options for those who don’t want to bother creating their own scripts. Sometimes also showing video previews for the graphical representation (useful when the operation is about cropping the image, or picking the exact millisecond where to cut). An example is LosslessCut, they keep a log of the ffmpeg calls… or maybe Shutter Encoder (press Alt+C to see the console commands).In Synaptic, the GUI package manager, pressing “Apply” calls the appropriate APT commands as a CLI app inside a VTE with the selection of the packages you have decided to add/remove/update, which you have previously selected in the listing that is generated from the GUI view of the app. Some people like having a graphical detailed listing which might be useful for conveniently browsing packages and seeing their detailed description, while still you get the raw information and accurate log from the installation that you would get when you are just using the CLI.