Hacker News Reader

Comment by almostarockstar | Hacker News Reader

What would you say are the merits of the terminal that a TUI encapsulates?

My opinion is that TUI is just a GUI with less fidelity. Being composed of text characters provides no additional benefit other than a retro style. The benefits of the terminal are outside of TUIs - composing scripts, piping data, bash etc.

View on HN

Vim keybindings, one of the most powerful and widely supported ways of interacting with information, basically impose the "grid of text" nature that define TUIs anyway, so my message prompt has to look like a terminal. The rest of the UI can be whatever, but grid-of-text works well for structured output, especially code blocks, as well.

TUIs compose with tmux. Pi's homepage says "use tmux" twice on it. It fits right into an already-mature ecosystem including a clipboard (powered by Vim visual / line / block mode) and easy integration with shells, editors, and other tools. GUIs generally have to re-invent all those wheels (tabs, splits, sessions, etc.) and it never integrates as well with other tools in a totally cross-platform way.

> What would you say are the merits of the terminal that a TUI encapsulates?

GUI scripting is still not a thing today. That's the biggest issue with GUIs.

Plus the mouse is genuinely bad for ergonomics.

Plus if you type _fast_ then TUIs are a great starting point.

Plus what's the equivalent of scrollback for a bunch of mouse clicks?

Plus TUIs are much more I/O efficient, which means running them over ssh/mosh/whatever is a great option.

Plus the shell is a programming language -- the GUI isn't just hard to macro-record/script: it doesn't even have a programming language you'd use for that.

I think the only point you made which is necessarily TUI-specific is the I/O efficiency / ssh point. Everything else is just a tendency of TUIs vs GUIs, but there's nothing preventing you from making a keyboard-centric GUI with no mouse support and built-in Bash scripting, or whatever scripting.

> Everything else is just a tendency of TUIs vs GUIs, but there's nothing preventing you from making a keyboard-centric GUI with no mouse support and built-in Bash scripting, or whatever scripting.

It has been 40+ years of graphical interfaces (58 if you include that Stanford Research Institute "mother of all demos" video). It's been about 10-20 years more for ttys, and TUIs in the form of screen editors go back to the mid-60s IIUC. Shells w/ tty interfaces go back to the mid-60s also.

So TUIs don't have that big a lead over GUIs, and clearly people take well to GUIs.

So maybe -just maybe- there is something about GUIs that makes them difficult to script.

IMO the bandwidth point is important, but not essential. Windows has had a high bandwidth local GUI since ~1990, and we've had RDP and such things be practical for remote access for about 20 years (i.e., since we started getting high-bandwidth networking to homes). In that entire time Microsoft and its developer ecosystem failed utterly to produce any sort of realistically useful and used GUI scripting or even just macro environment -- that stuff never materialized. There have been _attempts_, but none successful.

I believe the issue is a lot like web scraping vs. APIs. If you provide APIs, you can script those, no browser or GUI needed. But APIs are in short supply because:

  - GUIs come first

  - APIs require backwards-compatibility
    (which is a pain for the vendor)

  - [web-specific] APIs steal engagement
    (which is a problem for sites that
     depend on advertising)

That is a perennial problem for GUIs and BUIs, and it seems like it might be inherent to them, for how else to explain that this problem is never fixed? And yeah, scraping is not a good answer.

That's my 5-minute thesis. Expect the TUI to remain king for a while now that it's been reinvigorated.

Except, now that frontend design is now something an LLM can just shit out a reasonable looking webapp with buttons to click on your phone, why use a terminal? Sure, a GUI is never going to have the absolute composability of kubectl | grep that a shell has, but at the end of the day I want to click on the button and have it do the thing. I expect that because smartphones are terrible for running ssh from, that, with our new codegen powers, we'll see some innovation in that particular space. I don't want to hunt and peck on my phone's keyboard to ls and cd, but a TUI over ssh that I can use my touchscreen emulating mouse clicks on may be the sweet spot.

Text interfaces can offer precision and breadth of tooling that guis don't.

I do a fair amount of CAD so I'll use that example. Nobody who uses CAD professionally is clicking all the little buttons for tools. They're using commands, shortcuts, scripts, etc.

A GUI is slow and clunky. A textual interface, once learned, has way more degrees of freedom.

> They're using commands, shortcuts, scripts, etc.

Yes, power users often use shortcuts and automation, but how is that an argument against GUIs?

It simply depends a lot on the actual task. Certain things absolutely require a (high fidelity) graphical interface. Other things can be done just as well (and with less distraction) in a simple TUI. You can't generalize.

I don't think anyone referring to GUI means 'no commands/shortcuts/scripts', like, all of those that all CAD programs are GUIs that have commands, shortcuts, etc.

My two cents is that having all of your text be monospaced is not really ideal for agentic workflows where you do in fact read a lot of prose and in the future may want diagrams, rendered from a full browser's capabilities, etc.

I think I like the aesthetic of using a TUI because it makes me feel more like whatever 'real programmer' means to me... but I recognize its also cope.

(Also TUIs made a lot more sense when code was more expensive, because the monospacing constraint made it faster to build UI, etc.)

have you ever used, for example, vs code or Excel? both have robust GUI and keyboard capabilities. Andexcel has vba and now python and other scripting, and vscode is eminently extensible.

One small example - ChatGTP desktop intercepts highlighted text selection with "Ask ChatGTP" bubble. I have my own app that materializes a menu on highlighted text, but ChatGTP blocks it. No issues with that in the terminal. I am not a terminal junkie, but these opinionated paper cuts are annoying.

Reply on news.ycombinator.com