Lets call them what they are: a workaround to display graphical content in a terminal windows. We need them because SSH, because we linux UI is a mess, because UI is hard, in embedded, etc.
In an ideal world the concept of TUI would not exist.
Sometimes less is more. Having access to more features sometimes leads devs to bloat their applications and make them subjectively less usable.
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 do think that we are missing a good gui library that would direct developers to create lean applications (both from ux and resource consumption points of view) somewhat similarly as ncurses.
> In an ideal world the concept of TUI would not exist.
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 is just another way of writing portable UIs. Cross platform UI libraries exist, each with its own look and benefits, web-based UIs are another solution.
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.
This is like saying that books made out of text are a workaround for the movable type printing press, and with high-DPI laser printing in an ideal world the concept of text books would not exist.
