Live data from Hacker News

Stop Making TUIs

sockpuppet.org

441–450 of 580 posts

Re: Stop Making TUIs

#441
post #436

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces. I've been building my own TUI framework [1] and getting amazing…

When you're one of the people who finds TUIs inaccessible, "accessibility" isn't just a downside to be considered, it's table stakes. I think they're fine for one off toys for individuals and small groups, but if you're selling a product to the public, it ought to be accessible first and foremost.

That just means you have a potential userbase for an alternative for non-TUI people. If the market is that big, why not take it for yourself?

Re: Stop Making TUIs

#442

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces. I've been building my own TUI framework [1] and getting amazing…

> If we had a cross-platform usable GUI framework I could swear there once was a (n)curses or otherwise text based GTK+ implementation / backend. It didn't do everything of course, and this was, I don't know, about 2003-2007, but you could compile a GTK application and run it in the console. I tried finding a link, but unfortunately could not, can't even remember the name, I only remember building a piece of software…

Could you be thinking of libyui, but it was QT and ncurses based. I think it came from SuSE with YaST.

https://github.com/libyui/libyui

https://yast.opensuse.org/

Re: Stop Making TUIs

#443
This reeks of AI slop.

> Our field has a weird relationship with terminal and command line interfaces. The time has come to re-evaluate it.

Why? Why is infatuation weird? Why should we reevaluate it? The whole premise sounds like a "give me a hot take on XYZ".

(I built itter.sh so I'm biased)

Re: Stop Making TUIs

#444
Found this article to be a bit of a slog, burying the lede until after you’ve sifted through a rambling list of irrelevant vibe coded apps by OP. The actual argument came across in places but I am unpersuaded. Unsure if that’s due to the article structure or the argument’s own merits.

Re: Stop Making TUIs

#445
post #118

As a ratatui library maintainer, NO - please don't stop making TUIs ;) As a developer outside of that, I love the scratch the itch apps stuff mentioned in here. I have a vibe coded SwiftUI chess repertoire builder app that fits in that same sort of space that I'm currently working on, where I'd probably not have chosen to explore the idea if not for coding agents. I agree with the article that the terminal is an odd…

Grok Build uses your library and it has the best TUI of any app I've ever used. It has a lot of features that we take for granted in GUIs like scrollable regions, buttons, collapsible panes, and text selection.

I don't know why Codex and Claude Code haven't switched over; both apps have a terrible UI in comparison.

Re: Stop Making TUIs

#446

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces. I've been building my own TUI framework [1] and getting amazing…

Yeah TUIs are great. I'm shit at making GUIs but I was able to slap together a relatively simple TUI for some tooling at work, without any AI. Cheaper, faster, cross platform, less intensive. Most TUI frameworks nowadays have mouse support as well etc. So what if it looks just a little dated?

Re: Stop Making TUIs

#447

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces. I've been building my own TUI framework [1] and getting amazing…

I'm very keyboard-driven but I never really got TUIs. A GUI litterly can have just as good keyboard support, but because it doesn't force the user to use it, they rarely take the time to learn it. It's just always tempting to take the path of least resistance.

Especially becuase TUIs doesn't really have any of good properties that a CLI offers such as composebility. It's still a fixed UI with panes and menus which has just been squeezed into a character grid, and now forces the user to learn its pre-set keyboard bindings (which surely can be changed, but with every app having it's own config managment).

It's kinda the worst of both worlds to me. Either go all in and give me a proper text-based interface like Emacs (where you can globally configure how you wanna deal with lists of text in buffers), or just make a proper GUI with good keyboard support.

Re: Stop Making TUIs

#448
post #32

TUIs are just an accessibility nightmare without any of the advantages of a CLI like scriptability. Truly, Truly horrible

That seems at odds with many of the people in this discussion communicating that they find TUIs more accessible.

Re: Stop Making TUIs

#449
post #69

Earlier quoted context omitted.

How would that be any better though?

If the point is only that "terminal good because tabs" then that solves that problem

I read the point as "it runs in the environment I already use" for everything else, not "there are tabs".

Re: Stop Making TUIs

#450

Going into this article my attitude was "don't tell me what to do!" but I kind of see his point. Back in the late 1980s, there was no question—the Mac changed everything, and everyone agreed that graphical was the superior interface. But we in the Unix world were slow to convert fully, because of a couple of problems: * designing GUIs is hard, especially for programmers; * writing GUI code is hard (and often tedious)…

> Back in the late 1980s, there was no question—the Mac changed everything, and everyone agreed that graphical was the superior interface.

No, they didn't. The Mac's GUI benefitted in certain specific applications, like DTP, early on, but the Mac was an also-ran for most serious productive work for a very long time, and even when GUIs became standard in the PC ecosystem, it wasn't until the late '90s that productivity apps decisively moved from the DOS-based TUI world to Windows GUI applications.

> So good GUI apps really came from teams of elite designers and developers. The best ones all worked for Apple.

The folks who actually managed to build interface paradigms that successfully reconciled complex business functionality with sufficiently easy-to-master GUIs worked mainly for IBM and Microsoft. The CUA paradigm was the winner here.

People seem to forget that Apple had next to zero penetration into the business computing market, and nearly went bankrupt, back in the '90s.

Post reply on HN