Live data from Hacker News

Stop Making TUIs

sockpuppet.org

291–300 of 580 posts

Re: Stop Making TUIs

#291
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…

> To get a good terminal UX, ... At that point you're just inventing a new DOM variant and aren't fundamentally different from any other opinionated GUI framework. The value of the terminal for me is the minimalism. I absolutely despise all these new "features" that get added via protocols. I _want_ the boring grid composed entirely of extremely primitive character cells where WYSIWYG in terms of any underlying abstr…

The problem is that cells don't compose well as an accessibility thing. You need a DOM equivalent in order to realistically do a bunch of things that are meaningful at an app level. TUI libraries are all basically doing that DOM thing already - just custom and treating the final shippable product as the cells, positions and imperative instructions for how to tell a terminal what to do. I' just saying that a more declarative interaction is very likely the sort of simple and boring that helps portability (long term) and speed.

Re: Stop Making TUIs

#292
post #186

I think OP is missing the point of TUIs: They kinda work everywhere. While I need to fuck around with a operation systems native UI libraries like WinUI, SwiftUI, GTK, etc. I can just build an app in the terminal and be fine with it running on almost all platforms. I'd take TUI apps over electron apps everytime as long as the UX is good.

No. TUIs do not work everywhere. They can break because of terminfo which I really don't want to deal with. I hate wasting time on such configuration issues.

Re: Stop Making TUIs

#293
> Which is why I would never hand-write this program. Instead, I summoned it.

AI slop spam.

I don't want to use those AI sloppers. They often are not based on any intelligent design.

A good counter example is, in my opinion, htop. Many people use it, despite its ncurses-nature. It simply does what it wants to do well: give an overview over resource usage.

Yes, AI slop can spam-generate a clone, but why would I want to use that over the real thing? It makes no sense.

> I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful.

I don't want this spam slop anyway, but notice that the author became super-lazy. Rather than providing source code, he tells you to copy/clone it via Claude spam. So this human is now too lazy to do anything useful. Skynet won. He has been AI slop spam absorbed, without even noticing. Just like in the movie Invasion of the body snatcher (great movie, both the original and the first remake, though I liked the remake more, because Sutherland was in his prime back then).

The author continues to show more AI slop spam created useless things. None of which is interesting. I am surprised people now blog about boring AI created software and call it engineering. So, nah, don't stop making TUIs. Instead, design them better.

Having said that, I think ncurses is the wrong tool in general. We need to be able to design both TUIs and GUIs in one go without barriers. Every time I have to use ncurses, I do indeed curse.

Re: Stop Making TUIs

#294

Earlier quoted context omitted.

Those two are not contradictory statements

Maybe not, but they do sit on opposite end of an axis looking something like: TUI that runs on any OS |----------------| TUI without any compatibility mess You really can't have both at the same time, either you have great compatibility (which will be a mess), or you don't, to varying degree of course.

It depends. If the OS can run e. g. ncurses, you have access to quite a lot of software here, such as htop. Though, I am not sure if it works on windows; but I think it works on OSX. Windows is very strange.

Re: Stop Making TUIs

#295
post #279

Earlier quoted context omitted.

Except web. Which inexplicably got all of these when no one was looking

Not fast.

That depends what is build and how. Granted that a modern web browser is indeed an order of magnitude heavier than an OS, once that ticket is paid anyway, one can built very far, without relying on any additional bloat that contemporary web frameworks puts on top of it. There is not that much more data to send though HTTPS to bring a far more convenient UX than what raw text bespoke tweaks can offer over SSH.

Re: Stop Making TUIs

#296
> I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful. You see where I’m going with this.

This pretense that the entire value of source code is the "spec" / "requirement" is alarming.

The value of the code is how well-formed the spec is + how well tested it is in the real world. So prompt / mockup cannot replace code.

Re: Stop Making TUIs

#297

> Which is why I would never hand-write this program. Instead, I summoned it. AI slop spam. I don't want to use those AI sloppers. They often are not based on any intelligent design. A good counter example is, in my opinion, htop. Many people use it, despite its ncurses-nature. It simply does what it wants to do well: give an overview over resource usage. Yes, AI slop can spam-generate a clone, but why would I want t…

> I don't want this spam slop anyway, but notice that the author became super-lazy. Rather than providing source code, he tells you to copy/clone it via Claude spam. So this human is now too lazy to do anything useful. Skynet won. He has been AI slop spam absorbed, without even noticing.

and it "worked" - the audience he found for this is bigger than the previous one. So this continues until the AI psychosis become so high it start to turn people off.

Re: Stop Making TUIs

#298
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…

Damn, what an epic library name.

Re: Stop Making TUIs

#299
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…

> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc. Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?

charm.sh builds many such things. I love them and their personality.

Re: Stop Making TUIs

#300
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…

> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc. Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?

It’s trivially easy to run a TUI in a container. Not so much with GUIs. And, since I run as much as possible in containers, and as little as possible on my host machine, I much prefer TUIs.
Post reply on HN