Progress, who needs it.
TUIs could be designed in a similar way to GUIs, but the culture around their development is much different. So while TUIs aren't inherently better (and based on their limitations, they should be worse), they almost always are.
Probably because the average user is. I don't mean that offensively, but literally everyone on this site lives in a tech power-user bubble. The average user doesn't care to have a dense display of information, keybindings, and ways to input commands directly. They want an easy to use and nice looking app that does what they want.
For an app that's specifically meant for and targeting power users, that might be an acceptable choice to make, but if you want to target "people", then you're likely not going to be investing in power user features.
I found this toy to be very cute. Too bad my friends are not the typical software engineer that can use this. I'll just point them to a native macOS habit tracker on the app store instead. Friendly enough for them and efficient enough unlike the Electron alternatives.
Actual progress rather than re-creating the prehistoric 'good old UNIX days' or turning the users laptops into stove burners with many Electron apps running.
In GUI-land, this is hardly ever the case. I can't compose different software together, which is something I do all the time with the shell.
There are certainly some tools that work better as GUIs, but there are also tons and tons that really are great as terminal tools. No, this may not be a very approachable design for the average non-terminal-user, but that doesn't mean we should decry those who will find it useful. It's okay for different people to use different things.
I think I don't agree with the top-level comment in this thread that "everything should live in the terminal", and instead I believe what another response to that comment said: "everything should be exposed to the shell". Being able to compose tools is a huge productivity gain for those of us who care to do it and are used to it.
Assuming those programs have been written to be usable from the CLI to start with.
Likewise GUI applications can be written to be automated by REPL environments automation, specially if the OS exposes application IPC like COM, DBUS, XPC, Binder, REXX, ....
One contrived but possibly very common workflow for video creators: snip out a piece of a video with one tool, record new video from webcam with another, edit an image with photoshop, create sound effects in sfx util, create/record music with another, import all of the above into video editor and export a composited/rendered out video, do more lossless video compression/reduction with another utility.
- Messages (macOS)
- Slack
- web browser
- various notes apps
- iTunes
- Discord
- plenty more
These are tools I use all the time throughout the day. There is no simple pipe-like interface that allows me to easily take the output (graphical display) and pass it elsewhere to do something with it. In the terminal, everything shares a universal output system: text.
GUIs are not composable in principle. Sure, there are some workflows where you can do it, but that is not generally the case because they lack this common interface as a standard. CLI tools, on the other hand, have the standard of text output.
It is like the "Everything is a file", except when it is not.
Saying "Your point isn't true when there are exceptions" is a lazy argument, honestly. It is overwhelmingly the case that CLI applications use text as output, and my original point was specifically about how I wish this were more often the case with GUI applications — that you could somehow interface with them and compose them in the same way you generally can with CLI applications.
And yes even Microsoft does it, but what to expect when younger teams have the cool ideas to rewrite VS installer with node or use it to drive VS plugins.
Still not every graphical application is Electron based, whereas in what concerns the UNIX terminal hardly anything has changed in 50 years.
Modern UNIX has the necessary IPC tooling for REPL workflows like on Xerox Workstations REPL, Amiga REXX, Oberon, Powershell/COM/.NET, Inferno, yet the large majority uses it hardly any different from V6.
I want a thing in my terminal that I can use to track my habits
I would argue that people want a more traditional app instead, with what I'm sure you'd consider a bloated and inefficient GUI. Considering that most people don't even know what a terminal even is, and that form regularly trumps functionality in day-to-day lives.
I am arguing that what the parent commenter wants is valid, but is likely not what the general population wants.
In that respect, not sure how exactly your comment is relevant.
Perhaps I'm being overly charitable to the original commenter.
Ignoring REPL based workflows, structured IPC with GUIs apps for automation, ability to use any library directly, cramping text into a little window in a high definition screen.
Then since it is a full programming language REPL, not only you have text, there is also structured data to act upon.
On top of that comes the capability to directly access dynamic link libraries, the libraries of the language being used, and when the OS exposes it, application automation APIs.
So you can do stuff like select an open application, or something inside it, then switch to your REPL and execute some script over that selection.
Basically you open something like Jupyter Notebooks on the OS, and interact in a graphical way with everything that is running, not just executables that can only talk text via stdio.
Some real life examples, were the Xerox PARC workstations (Interlisp-D repl, Smalltalk transcript, Mesa/Cedar devenv), AmigaDOS shell with REXX, OS/2 with REXX as well, Native Oberon with its command modules, and for something more up to date, Powershell with COM/DLL/.NET/OLE Automation/WMI integration, AppleScript / Automator.
In modern UNIX clones something similar could be achieved via DBUS, KParts and a scripting language of your liking, like Python, Ruby whatever, but it remains a niche thing.
https://www.freecodecamp.org/news/python-for-system-administ...