Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Making TUIs

sockpuppet.org

Post reply on HN
Print view View original

81–90 of 579 posts

Re: Stop Making TUIs

#81

Post by benj111 »

zmmmmm wrote: post #40

Make more TUIs .... The main thing I like is that TUIs are guaranteed to be navigable by keyboard. So many non-TUI apps don't include shortcuts at all for critical actions. It makes the first week of using the app more efficient and the entire rest of your life less so. Add on to that, I can probably run a TUI on my server. Or my cloud instance. And in my sandbox. Over SSH. So: do make TUIs and bind their keys to Vi-…

>The main thing I like is that TUIs are guaranteed to be navigable by keyboard

I don't disagree with you, but in ye old days you had guis that were navigable by keyboard.

And these were discoverable. That one program you use every day, you can spend the time to learn the short cuts. You can still get things done by clicking around though.

I suspect the underlying issue is one of limitations. Terminals are limited in what they can do. Guis and the web, you can do so much more, so people do.

I think another issue is touch screens. Guis and the web have moved to optimise for those. It decreases information density, forces a move away from the old standards to new much weaker ones. Tuis can't really do touch, so they don't have to make those tradeoffs.

Re: Stop Making TUIs

#82

Post by mike_hearn »

GreenSalem wrote: post #8

Incoherent and far too long . Lists a bunch of things . Fails to make any clear points . Fails to give real reasons for the few claims it makes .

Did you read it all the way to the end? It's coherent and does give real if debatable reasons for the claims it makes, I think it also does so quite clearly although if I'd written it the ordering of the sections would be different.

Here's an organically grown summary:

• TUIs suck because they are primitive, often buggy, hard to write and aren't accessible. Their existence isn't due to any real technical advantage but more because UNIX historically had a very bad UI toolkit (Motif) which established a 'culture' of TUIs.

• It's now easy (on macOS) to write native apps that use SwiftUI and give a much better GUI. You can just vibe code them.

• Some specific skills, features, templates etc are linked which look useful if you agree with this approach.

• You don't have to give up remote access because there's no reason the GUI has to run on the same machine as the thing it controls. A native GUI can just SSH in to a remote machine and run non-TUI CLI tools to control it. Lots of apps have worked this way and it functions fine.

• On the other hand, TUIs are portable (ish). The author concedes this may sometimes be useful.

Re: Stop Making TUIs

#83

Post by benj111 »

alerighi wrote: post #59

To me TUI have a better user experience than graphical applications. And considering the amount of companies that are still using decades old AS/400 systems instead of new ERP system I'm probably not the only one to think it like this. First, a TUI is usable with only the keyboard. Moving the mouse is a waste of time, and if you are using an application multiple hours a day, it can lead to being more productive. Seco…

The real shame though is that you can make gui apps efficient.

I've used the same systems you describe, except in gui form.

And the thing is, with this kind of application, everyone has a different 20% that they spend 80% of their time using. Guis can be as good as the TUI in the 80%, and very handy in the 20% where you aren't so well versed.

The issue, is that guis seem to have dropped the ball with regards to efficiency.

Re: Stop Making TUIs

#84

Post by benj111 »

swiftcoder wrote: post #48

As someone who works on a very GUI-centric OS (i.e. Mac), TUIs just don't integrate very well with the rest of the non-Terminal ecosystem. They don't support standard GUI shortcuts. They don't support drag-and-drop. I can't double-click a file and have it open in a TUI. They don't integrate with spotlight metadata. They don't ship document icons. They have terrible support for accessibility APIs. And so on...

It's somewhat an issue with Linux as well.

Ctrl c does 2 completely different things. Terminology is different. Etc.

Problem is. Terminal applications standardised in the 70s. Guis in the 90s. Although that's being undone by web apps, and the influence of touch screens.

Re: Stop Making TUIs

#85

Post by benj111 »

skeledrew wrote: post #57
danpalmer wrote: post #6

Earlier quoted context omitted.

What do you like about them? I disagree, but so many people seem to like them that I assume I'm missing something. The main one I've heard before is that they work nicely over SSH, but I assume there must be more?

It's easier to automate TUIs, since it's just text.

Nit. Surely it would be keyboard navigation? Your macro can consist of the key presses you would actually use, rather than trying to describe mouse movement.

If you want to automate from the perspective of what's on screen, tuis have no metadata. A button in a gui does have metadata associated with it, so you could automate 'click button x' where as in a TUI you'd be limited to clicking 'position x,y'

Re: Stop Making TUIs

#86

Post by lelanthran »

hiAndrewQuinn wrote: post #68

I like TUIs, and I chose to build e.g. https://taskusanakirja.com/ as a TUI for a couple of reasons, some of which are in this article and some not. Cross platform compatibility was a big one since at the time I started building it I didn't actually have a Windows or Mac machine handy to test this out. One thing I think which is overlooked is the raw feeling of speed a good TUI can give you. The lowest grade consumer…

> One thing I think which is overlooked is the raw feeling of speed a good TUI can give you. The lowest grade consumer laptop could probably download my little dictionary program and still get true search-on-keystroke performance, because there is virtually nothing slowing down that path, no animations, no nothing. Now most of that comes down to the data structures involved and making sure nothing ever has to go over a network, but I still appreciate the sheer simplicity of the approach.

Recently, I posted a GUI mp3 playing program written purely in Tcl/Tk using shell scripts for some things. On my 2011 desktop, filtering for a specific mp3 across all the mp3s stored on my computer (about 80GB of mp3s) takes single-digit milliseconds. I can only imagine what a modern desktop, with an SSD, will do!

GUI apps don't have to be laggy. My Qt and Lazarus apps aren't laggy at all, and are far more snappy and responsive than the clear majority of TUIs I use (like CC).

Re: Stop Making TUIs

#87

Post by jmorenoamor »

danpalmer wrote: post #6
jmorenoamor wrote: post #5

No. I like them.

What do you like about them? I disagree, but so many people seem to like them that I assume I'm missing something. The main one I've heard before is that they work nicely over SSH, but I assume there must be more?

A good UI can be text, graphic, voice, etc.

I enjoy the usability and self perceived speed of not having to leave the console or reach the mouse to move a pointer when a cople of key presees is enough.

It's a matter of choice, I know, but I also think there is a genuine case for text over graphics. I see it everyday on businesses that keep old cobol tpvs at the cash, the speed at which the clercks check inventories or perform other crm activities is unmatched to mouse or touch interfaces

Re: Stop Making TUIs

#88

Post by farhadhf »

The CLI/TUI split in the article is right, but to me the more interesting boundary now is human-facing vs agent-facing interfaces. For most things TUIs lose on both sides.

We run an internal agentic development harness we experimentally built for working on large-ish projects. first version started as a TUI, but it quickly became unusable for the large scale projects it was meant to work on (essentially PRD to PR, with planning loops, task decomposition loops and dependency aware execution / review loops). The TUI was too state-bound for another agent to drive reliably, and too cramped for a human to review at scale. We ended up replacing the TUI with a headless cli, and every interface we've built for the harness has become either a text artifact (mostly for agents to work) or a web view (for humans to drive and review).

Re: Stop Making TUIs

#89

Post by croon »

annapanna wrote: post #76
nimih wrote: post #33

Earlier quoted context omitted.

I personally like making (and using) TUIs because: - They encourage developing simpler, information-dense, and keyboard-driven interfaces, which I tend to prefer in general. - I find them more fun to write, and less aggravating to maintain and debug, than interfaces built with GUI toolkits. - Most software I write for personal use is going to be run in both a Linux and Mac OS environment (and a lot of the time on a h…

But you can't really do information dense when you are limited to a fixed grid of monospaced character glyphs. Variable width fonts are much more information dense for example.

I prefer TUIs personally, but I can't see myself use maps, or visual image editing in a TUI for example, but is vi infinitely faster than vscode for manipulating a codebase? Absolutely.

Anything that lends itself to keyboard input, piping, text manipulation and a bunch of other things are so much faster if you're equally proficient in both input modes.

Re: Stop Making TUIs

#90

Post by cube2222 »

Yeah, I think I agree with this. I think making GUIs and reverse engineering proprietary APIs are two things that frontier models make really pleasant - e.g. I made a menu-bar app (very similar to your temperatures dropdown, similar graph, SwiftUI) which connects via bluetooth to my Inkbird CO2 sensor, graphs the CO2 level over time, and looks fabulous.

The skills are useful, thanks for linking them! They'll be useful for my future projects like this. FWIW I've had good luck with using Claude Design first to do mocks.

At the same time, I think there's still the "is this worth doing a hyper-customized version of this software, if I'm also then responsible for fixing the bugs?". But I think increasingly as we improve our agentic workflows and make them more self-contained loops driving the result to completion, this becomes kind of a non-issue.

In general, I do think LLMs are bringing about a new age of hyper-customization, which I welcome.

Post reply on HN