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

151–160 of 579 posts

Re: Stop Making TUIs

#151

Post by anon7000 »

barnabee wrote: post #39
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?

IMHO the rise of TUIs is heavily correlated with the near-abandonment of professional quality graphical interfaces. If there was a powerful, information dense, configurable docking/tiling, multi-application-composing GUI framework (all things a good terminal can do) then yes, build everything in that. I’d love to see it. Until then, TUIs are vastly better than another Electron app or Mac app using UI frameworks that…

Nailed it. As the blog post says, GUI’s aren’t normally written for nerds. They exist, but it’s not normal.

So even professional tools all follow industry design and product trends which are too simplistic, don’t give you the info you need, and are optimized for abstract brand design or chasing metrics for the company, and not optimized for “how do I let my user accomplish their task as fast as possible”

Re: Stop Making TUIs

#152

Post by anon7000 »

TurboHaskal wrote: post #11
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?

I don't think TUIs are inherently better but some are simply too good versus the alternative. magit and k9s for example.

Also CLI args to TUI are very useful. Like the k9s command flag to take you to any view. It feels more immediate than launching a separate app from the terminal

Re: Stop Making TUIs

#154

Post by jbstack »

sjbzbeiks wrote: post #137

Tabs vs spaces. I’ve always appreciated the positive side of TUIs and appreciated less the positive side of GUIs. I didn’t grow up with a computer at all and in one of my first adult jobs I had to use a TUI at Papa John’s for punching in orders, it was 20x faster than anything I used after it at other restaurants that were GUI driven (keyboard speed wins for me, fit my brain perfectly). I think I learned it in 5 minu…

I like TUIs for largely the same reasons as you, but I don't think this is actually a valid criticism of the article. It specifically addresses this by pointing out that you can make your GUI keyboard driven if you want to, so this isn't really an advantage of TUIs per se. It just happens that TUIs tend to be keyboard focussed while GUIs tend to be mouse focussed. But that's a design choice rather than an inherent property of TUIs vs GUIs.

I agree that I found the article to be poorly written. Mainly because it takes a long time to make its point. I didn't really need to see a million examples of the author's vibe coded slop before getting to the topic which the title suggested the article would be about.

Re: Stop Making TUIs

#155

Post by raincole »

inatreecrown2 wrote: post #139

The nice thing about TUIs is: they are platform independent. Whereas with SwiftUI apps you are bound to macOS.

TUI apps are only platform independent if you make them so.

GUI apps are only platform independent if you(r framework) make them so.

It's a quite common illusion that TUI apps are "automatically" platform independent. Even knowing which terminal emulator intercepts which shortcuts and how they handle width change, control character, mouse events, images, etc and design around them is not a trivial task.

On the other hand, making platform independent GUI apps haven't been easier. Just use Electron. Yes, performance blahblah, but thousands of Electron apps work on millions of machines just fine.

Re: Stop Making TUIs

#156

Post by jbstack »

codethief wrote: post #130
PaulRobinson wrote: post #42

Yesterday I was flipping between some TUIs, native apps, web apps and an electron app. I think it was only because I was trying to do a lot in each of them I became really aware of the latency lag in some of these. There are real advantages of TUIs: less CPU; sometimes I want to be using a personal TUI on a personal dev server quickly from a work laptop at lunchtime and an ssh + tmux + TUI is perfect; most modern TUI…

> I think it was only because I was trying to do a lot in each of them I became really aware of the latency lag in some of these. While I get your point, a lot of vibe-coded agent TUIs (Claude Code, GitHub Copilot CLI, …) aren't exactly fast, either.

A lot of vibe-coded GUIs aren't fast, so this particular issue changes nothing. You're describing a property of the software development method, not TUIs vs GUIs.

Re: Stop Making TUIs

#157

Post by blipmusic »

Keep making TUIs. Keep making whatever you want. These "terminals weren't made for that" kind of comments are a bit tiresome. I can run TUIs on machines I only have ssh access to and they are often leaner than the corresponding GUI variant - though perhaps less so with today's fancier TUIs. 'top' has a TUI and isn't exactly new, some interactivity - yes, even in a terminal - can be nice.

I'm currently trying to create a GUI version (immediate mode library) of a CLI tool of mine and it's mostly a shit show and three times the work of a data-in-data-out CLI tool. Good learning experience, though. I should note that I don't care whether the GUI version has a "native feel" or not (if you have the time to do so, be my guest), only whether it's functional and reasonably fast, since otherwise that's even more work for an open-source tool. Though, when I undoubtedly make the more interactive TUI version later on (ratatui just seems too nice not to try! :-)) it will probably bring a similar complexity development wise.

Then again I'm not into agentic coding at all so maybe the joke's on me. On the other hand, at the moment I need to learn about the data I'm processing, the GUI library/framework I use, and being able to help the people I work with troubleshoot the equipment that collects said data. I'd miss out on most of that if I coded by prompt. Perhaps I'll try later, perhaps not.

Keep making TUIs, or GUIs for that matter.

Re: Stop Making TUIs

#159

Post by jbstack »

curtisblaine wrote: post #55

Clickbaity title. Boring show off of vibe coded apps that only make sense to the author, disguised as think piece. This post has it all.

I found most of the article completely unreadable. I was actually beginning to wonder if the HN post had linked to the wrong article, as it had nothing to do with TUIs until the very end. It was just a long list of "look at this slop code I made" and "look, here's another one!".

Re: Stop Making TUIs

#160

Post by jbstack »

joshka wrote: post #119
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 .

I really liked this article (despite disagreeing with its conclusion and agreeing with many of the concerns about failures of TUIs). It gave a feeling of "here's a bunch of cool stuff I've done" to help back the claim, which is far more personal than a lot of blog posts tend to be.

Except there was nothing "cool" about them. Vibe-coding ugly looking GUIs with slop-code backends is not interesting or impressive in 2026. Literally anyone can do it, and I'm pretty sure 90% of HN readers are aware that it's possible. Plus it did nothing to further the claimed purpose of the article, which was to explain why you shouldn't make TUIs.
Post reply on HN