Hacker News Reader

Comment by pcr910303 | Hacker News Reader

CLIs (that read input from stdin and spit out results to stdout/stderr) are useful in an automation/data processing pipeline. But TUIs are a gimmick that should have been just GUIs. (And text selection is not a reason to resort to TUIs — it’s a reason to improve GUIs.) Unfortunately native GUI programming doesn’t have the coolness/geekiness factor of TUI apps…

Edit: Looks like I should clarify – I'm not saying that people should stop creating TUIs right now: in the current landscape, TUIs do have advantages like being usable over ssh, text selection, a simpler programming model in most languages... but I'm arguing that these advantages aren't inherent to TUIs. We should aim to improve GUIs, not stuck in a interface from the 70s. Unfortunately I've seen too many people (including a big chunk of HN) that argue that TUIs are just inherently superior.

View on HN

I can make a TUI by just reading from stdin, writing to stdout, and some minimal parsing and emitting of VT codes that have mostly not changed in a few decades.

To make a GUI I have to pull in megabytes of libraries, learn their API, then update them every time they release a new version that will likely have breaking changes. They'll also have questionable bindings outside of one or two "first-class" languages, so reading docs and investigating why something isn't working is harder.

I'll stick with TUIs, thanks.

Web interfaces are the GUI equivalent of the simple, timeless tty interface. My 10 year old router still renders html just fine on modern Chrome.

Yes, but at the cost of needing to run a browser. In this modern era of everyone fetishizing single-instance applications, a browser crash caused by one tab would mean I lose not only all my open websites but also all these "apps".

I have to `pkill -9` firefox once every few days because of bugs; a few months ago it used to break the clipboard until it was restarted, these days it freezes when dragging tabs around in the tab bar, tomorrow I'm sure it'll be some new bug... I'm glad I don't lose my editor / IDE / chat clients / monitoring dashboards when this happens.

And after all that work you can't even use your GUI over SSH.

Sure, with X11 forwarding.

You can't use your GUI over 9600 bps serial port (yes this is sometimes still relevant).

Or even just a shitty wifi connection in an underdeveloped region or area.

The major desktop and workstation operating systems usually have an SSH client installed by default. The same cannot be said for X11. It is easy enough to use X11 on a mobile device. You may be able to get an X client for a mobile device, but I wouldn't want to use it.

(Not to mention that some X11 software doesn't seem to work across the network these days, which causes me no end of frustration since RDP is usually fantastic. Not to mention the bandwidth requirements of graphical sessions, which is a concern over mobile networks.)

Windows doesn't have an SSH client installed by default. But I agree with your point - setting up SSH is way easier than X11 and X11 doesn't even work that well over the internet.

VNC would be a more reasonable answer but that is a pain to set up server-side on Linux and isn't very good. Really NX4 is the answer but it costs an absolute fortune.

Web UIs solve most of that - even easier to implement than TUIs and you can use them remotely.

The only big issues I have with them are security (most don't restrict connections to the same user and I wouldn't be surprised if a lot of them listen on 0.0.0.0) and launching them. There isn't a good cross-platform way to launch a browser.

That's an argument for making GUI libraries more ergonomic, not to keep making TUIs. And TUIs made by "just printing VT codes" will break when you resize the terminal, change the font size, or more.

TUI's can deal with changes in terminal geometry, generally by redrawing. It even works in a telnet/ssh connection, the remote host gets sent that information and uses it accordingly.

Yes, it does. But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program), and you lose the aspect of 'creating TUIs are just printing VT codes'.

Redrawing a TUI from scratch is usually trivial. Certainly far simpler than your average GUI.

It's far less complexity, even still, and it has not changed much for decades. A TUI program working today will likely continue to work for decades more. If you don't care about glitz and just want to write something useful, that's a substantial draw.

> But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program)

No way dude. All you need to do is catch SIGWINCH and then ioctl/TIOCGWINSZ to get the new size. Back when I was into roguelike development, responding to the terminal resizing took scarcely more than a half dozen lines of C. I wish I knew of a GUI system this simple.

Most GUI systems handle redrawing and resizing for you. Likewise you may need to catch some events, but that's it. Which GUI are you talking about?

It's not redrawing/resizing with a GUI that's the matter, it's the whole of it. TUIs are easy to create without much investment in learning a whole GUI system.

That's assuming you find a TUI easier to deal with. I guess for the I-use-Arch crowd, sure, but anything more than just printing out lines of text IMO makes using VTs a pain. And if I'm just outputting text, using GTK or Qt is more than fine.

Still not much complexity.

Right, I don't think you and OP are in conflict at all. Basically, GUIs presently suck. The average perfomance differences between TUI's and GUI's point directly to the fact that GUIs are very very bloated. There's no reason that a GUI shouldn't be as performant as a TUI, given the relative minimum it ought to take to convert one to another. A little vector here and raster support there should mostly take care of it.

Then you make your software unusable for everyone who needs to use languages other than English. For example, I can't reliably type Devanagari (the script used by Hindi, Marathi, Nepali, and a bunch of other South Asian languages) into any terminal on any operating system.

You also make your software unusable for people who use assistive software. TUIs are not accessible by default, GUIs can be with only a tiny bit of effort.

TUIs are perfectly fine for internal tooling, but any piece of software intended for general distribution should ship with a proper GUI. Even a basic Electron UI beats TUI in terms of accessibility and internationalization support.

My terminal (foot) supports IME just fine, using the same protocol that a GUI application uses.

It's not just about the IME. I'm on macOS, where it's possible to type Devanagari/Gurumukhi into both iTerm and Terminal.app without any issues.

However, neither of the emulators can render the typed text correctly. I tried typing "नमस्ते" into both just now, and they both broke in different ways.

Here's iTerm failing to render a half स: https://imgur.com/a/vg1i4aB

Here's Terminal.app messing up how the quotation mark gets rendered: https://imgur.com/a/B5zd85V

Can foot handle this case? What about GNOME Terminal, Konsole, and Windows Terminal? If I can't reliably read Hindi text on the commonly used terminal emulators on all three major operating systems, then from my perspective a TUI app is worse in every way compared to a native GUI app or even an Electron app.

How is this, in KDE's Konsole?

https://imgur.com/a/xYjUQRv

I have exactly 0 knowledge of Devanagari/Gurumukhi but I think the issue is this vertical bar that shouldn't be there when those characters are next to each other.

https://i.imgur.com/DcMGta0.png

I see, thank you.

(I'm a native Hindi speaker.)

It's not wrong. Note that it's not a single vertical line, but a line with a smaller line below it (a halant). This has the same meaning as not having that line entirely, namely that the letter is a "half-sound" s rather than a "full-sound" sa. It's just that nobody would write it this way as part of the word namaste; it's only used when talking about the sound standalone or when the half-sound is at the end of a word. (The latter is rare in Hindi, because Hindi is less precise about denoting half-sounds at the ends of words, compared to something like Sanskrit.)

However the halant does seem to be cut too short, perhaps because it's exceeding the terminal's line height. The terminal may need to be configured to use a smaller font size for the Devnagari font. The halant renders fine in foot without having to tweak the size, but of course it depends on what font is getting used in my case vs yours.

Another problem in that picture is that the horizontal line between the n and m has a tiny break, which it shouldn't.

Thank you for your input. I've filed an issue with your comments here: https://bugs.kde.org/show_bug.cgi?id=451716

If you have other issues that you would like me to check, just reply back here. Thank you.

TUIs are GUIs, just different tech.

Many times you don't have graphical access to the machine. As an example, `htop` is very useful when I don't have access to `gnome-system-monitor`.

Couldn't agree more. A good GUI beats a TUI any day. They have the potential to be far more intuitive as well as more aesthetically appealing. Not to mention that for some of us, a GUI gives far greater confidence than a TUI.

For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes.

I do think GUIs can learn a few tricks from TUIs. TUIs are often more responsive and usually provide better keyboard driven workflows.

Ultimately my preference for GUIs probably reflects what I'm used to. To paraphrase Jef Raskin, there are no intuitive UIs, only familiar ones.

>For example, I prefer to do package management from the command line, but if I'm editing partitions, I feel the urge to use a GUI like Disk Utility or gparted. For this task, GUIs feel safer for a few reasons. I feel like I can better visualize the changes being made to the drive, and it seems like there are more speed bumps to prevent dumb mistakes.

cfdisk, cgdisk.

Maybe you are afraid of parted/fdisk. Then you are right.

But well, fdisk and such are a bit "nightmarish". I had more luck using OpenBSD's disklabel to slice up it's own partitions. And the GPT editor from OpenBSD (I can't remember it's name) was pretty simple to use and preview even on text mode.

You can have both good and bad CLI/TUI's, and even horrendous GUI's, such as the Red Hat installer.

One of the nice things about TUIs is the removal of visual clutter and other forms of distraction.

I also recall an article a while back about Emacs and screen readers. Since everything has to be representable as text, rather than accessibility being an afterthought, it was usable with screen readers. I imagine something similar can be said for those who need better contrast or large text, since terminal colour schemes can be defined by the user and software has to handle variable terminal sizes.

One reason GUIs aren't as cool as TUIs is ... people don't want them to be.

Growing up with TUIs, I was quite surprised how often people refuse to use a program because it doesn't conform to the "native" look and feel. I've found plenty of people who'll happily use htop in the terminal, but then complain when a GUI app doesn't respect some tiny aspect of look and feel. Even things like the placement of "Options" or "Preferences" in the "wrong" menu causes them ire.

For whatever reason, people just seem to expect different things from GUIs.

> CLIs (that read input from stdin and spit out results to stdout/stderr) are useful in an automation/data processing pipeline.

TUI's and GUI's can both be used in the middle of a pipe when things require some manual fiddling, Git commit would be an example of this, opening vim to edit the commit message. Here's an example (https://stackoverflow.com/questions/8371877/ncurses-and-linu...) of how you could create an ncurses TUI but still output to stdout.

Dmenu (https://tools.suckless.org/dmenu/) is a good example of a gui program that fits comfortably in a pipeline.

> TUIs are a gimmick that should have been just GUIs.

I mostly agree. I use Midnight Commander a lot but I'd prefer a basically identical GUI version with the same keys. None of the Linux GUI orthodox file managers I looked at were comparable, though I didn't do a comprehensive search. (Edit: There are tons of GUI orthodox file managers for Linux. I was wrong.)

The main advantage of a TUI to me is that it is available over SSH more easily. X forwarding exists but I never recall it being particularly responsive.

As another commenter says, TUIs also have advantages in terms of coding.

Didn't Midnight Commander come with a GTK+ based graphical version back in the day? It was the first file manager component in GNOME before Nautilus replaced it.

X forwarding works great with traditional apps using oldschool toolkits without any bitmap chrome and all text rendering deferred to the server.

Ideally!

In practice, for use cases where you're spelunking through different directories and running different commands: you're going to have an easier time either staying in a terminal (where opening a GUI to perform a task is awkward), or an easier time sticking with a GUI (where opening a terminal to run a command is awkward).

Currently, TUI provides many of the benefits of a GUI, without having to leave the terminal.

TUIs definitely have their place. For starters, a lot of terminal applications really don't need anything from a GUI. And GUIs carry some weight that will not be shed:

- The required libraries you need to install for them. A docker image with TUI tools can be light, with GUIs it will be heavy.

- Usability over SSH is definitely a TUI inherent advantage. X forwarding is an absolute mess, and even if someone tried to improve it probably would still be a mess. Executing code in a remote machine and sending the graphics to another system (possibly with different graphical interface or even operating system) is never going to be as responsive or integrated.

GUI's can be too slow and too heavy. Good TUI can be hyper fast user wise.

TUIs are designed to be used without a mouse and are ligtning fast. Information is condensed due to limitations to text only. By the time you open a GUI you lose or corrupt your thought process when bombarded with more visual information than the little change you wanted to make. TUIs are great for a quick in and out while GUIs are great to linger there for a while. And do some click click clicking.

Having started programming in a time where all we had were TUIs and GUIs were only accessible in expensive workstations (first computer, a Timex 2068), I also don't get this adoration for TUI and CLI.

They are a reflection of a time when I would like to have more and it was out of reach.

We used them because it was everything we had access to, that is all.

> I'm arguing that these advantages aren't inherent to TUIs.

How do you use a GUI app inline inside a screen session? And I mean _use_ it inside, not launch a floating GUI window that's disconnected from your entire workflow.

There are advantages to remaining inside the terminal, for those who are comfortable with the terminal.

TUI's are very useful over ssh, where existing ways of remoting GUI's have way too much overhead.

Reply on news.ycombinator.com