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

111–120 of 579 posts

Re: Stop Making TUIs

#111

Post by hombre_fatal »

annapanna wrote: post #73
hombre_fatal wrote: post #50

Earlier quoted context omitted.

Which desktop? It's not true for AppKit, SwiftUI, GTK, Qt, WinUI, or Electron, and I'm not sure what's left.

What? 99% of my programs I can open more than one window by just executing the program as normal multiple times, the only ones that enforce a kind of singleton execution are things that also acts as a kind of server, one example is Everything search, but it has a "Open new Search window" for multiple windows. And that is the default, you have to explicit code in a lock/global mutex thing to block multiple instances.…

Anything from WhatsApp to the Settings app on macOS where I might want to, say, compare the wifi network settings for two access points.

But the point is that the developer has to build the app in a way that lets you do this.

Once again, there is no default with the tools I listed. You decide on how you want windowing to work and then build it.

At this point, show me examples of needing a mutex to "block" a multi-window default.

Re: Stop Making TUIs

#112

Post by hombre_fatal »

mike_hearn wrote: post #79
hombre_fatal wrote: post #21

One of the biggest upsides of TUIs over GUIs is that I can run any number of TUI instances. Meanwhile a GUI's developer has to decide to grace me with the ability to even open more than one window. "A tabbed interface will be sufficient!" -- yay, I'll never be able to view two screens of info at the same time.

Only if the program is designed to be safe to run in parallel. Which can be done with desktop apps too - and they'll run more efficiently as well, as the windows share memory.

GUIs have their benefits. You can make much richer UIs with much nicer UX when you're not limited to a grid and whatever paradigm you can hack into the ancient tty stuff, and when you have access to raw keyboard scans.

But I don't think I've run into a TUI that I couldn't have multiple instances of.

Re: Stop Making TUIs

#113

Post by hombre_fatal »

underdeserver wrote: post #67
hombre_fatal wrote: post #21

One of the biggest upsides of TUIs over GUIs is that I can run any number of TUI instances. Meanwhile a GUI's developer has to decide to grace me with the ability to even open more than one window. "A tabbed interface will be sufficient!" -- yay, I'll never be able to view two screens of info at the same time.

But in the article all these GUIs are vibe coded. Tell your AI to allow more than one window. What's the problem?

Then you'd have to contend with the rest of the list of TUI advantages over GUIs, like trivially operating them as they run on remote machines.

Re: Stop Making TUIs

#114

Post by orbital-decay »

hombre_fatal wrote: post #110
orbital-decay wrote: post #107

Earlier quoted context omitted.

Huh? None of these force single-instance by default

They don't do anything by default. The developer makes it do what the developer wants (not the user). You claimed the developer has to "actively block it" which isn't the case. Even in SwiftUI which has the simplest way to support multiple windows with zero work, the developer has to use WindowGroup, and if they didn't then you don't get to open more than one window.

I did not claim it (another user did), but I think your reaction captures the overall sentiment ITT, which is taking perceived status quo as some fundamental thing and defending the worse solution instead of changing the status quo. If all that energy went into perfecting GUI apps the way you want them to work, the ecosystem would have been much healthier. I've seen it in Electron already, and TUI apps are headed the same way, it's simply inevitable. The JS and Python bloat and fragmentation of conventions are already there, reinventing things that used to be simple in a complex way is next (in a way it already happened, e.g. a ton of basic things like hotkey schemes have to be reinvented from scratch each time in TUIs).

Re: Stop Making TUIs

#115

Post by hombre_fatal »

orbital-decay wrote: post #114
hombre_fatal wrote: post #110

Earlier quoted context omitted.

They don't do anything by default. The developer makes it do what the developer wants (not the user). You claimed the developer has to "actively block it" which isn't the case. Even in SwiftUI which has the simplest way to support multiple windows with zero work, the developer has to use WindowGroup, and if they didn't then you don't get to open more than one window.

I did not claim it (another user did), but I think your reaction captures the overall sentiment ITT, which is taking perceived status quo as some fundamental thing and defending the worse solution instead of changing the status quo. If all that energy went into perfecting GUI apps the way you want them to work, the ecosystem would have been much healthier. I've seen it in Electron already, and TUI apps are headed the…

I don't understand what you're responding to.

TUI apps are multi-instance by default since the user can invoke the program in different pty sessions. The developer would have to actively fight that.

GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window.

Whether things might change in the future isn't relevant because we're talking about how things are today, not speculating about the future. And the time to change one's opinion is when reality changes, not ahead of time based on how you think things hopefully will be.

Re: Stop Making TUIs

#116

Post by 0x457 »

throw83949390 wrote: post #19
0x457 wrote: post #3

Earlier quoted context omitted.

Huh? Qt, GTK, Cocoa (AppKit and UIKit), bunch of other linux friendly gui frameworks been around for a long time, even Flutter is still around. What is being killed?

What versions of QT and GTK? Running GTK1 or 2 apps is pretty hard. P TUI apps from that era work just fine! The same reason webui and js is so popular!

There were 4 (four) major versions of GTK since 1998. You're telling me that rate is faster than you can learn? Maybe you just a slow learner.

Re: Stop Making TUIs

#117

Post by 0x457 »

worthless-trash wrote: post #18
0x457 wrote: post #3

Earlier quoted context omitted.

Huh? Qt, GTK, Cocoa (AppKit and UIKit), bunch of other linux friendly gui frameworks been around for a long time, even Flutter is still around. What is being killed?

gtk1/gtk2/gtk3 code will require you shipping gtk(version) on modern linux, not all distros have the legacy libraries. Apple deprecated carbon (which was a thing when gtk1 was around). I don't think you have an option for this on their ARM hardware. QT1->N code has the same problem, the older libraries are not shipped on most modern linux. I do absolutely understand if you're going to do static compiles, that can wor…

Carbon was released in 2000 and final release was in 2019. Cocoa, correct me if I'm wrong, was released in 2005. That's 14 years to learn it. Not like you knew Carbon when Cocoa came out because there were like 10 developers making Mac OS X apps before 2007.

y'all are slow learners if that's an issue for you, but React doing major breaking changes at least once a year is totally fine.

Re: Stop Making TUIs

#118

Post by joshka »

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 shape which you're fighting against historical specs, etc. The key observation I have though is that the mismatch of terminal apps and libraries to deal with this are all fundamentally built around character cells and cursor movement plus various CSI/OSC/ASC/DEC/xterm/... protocols which are complex and have varying support and interact in weird ways.

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.

I know Mitchell Hashimoto has a bit of a different perspective on this, which seems like it's to define some more protocol stuff and continue to build up on things. I think that probably gets to 95% pretty well. But a 100% good is a full replacement.

Re: Stop Making TUIs

#119

Post by joshka »

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.

Re: Stop Making TUIs

#120

Post by 0x457 »

Shank wrote: post #27
0x457 wrote: post #3

Earlier quoted context omitted.

Huh? Qt, GTK, Cocoa (AppKit and UIKit), bunch of other linux friendly gui frameworks been around for a long time, even Flutter is still around. What is being killed?

Apple believes SwiftUI is the future, not AppKit and UIKit/Cocoa.

Sure, Apple positions SwiftUI as its primary forward-looking UI framework, but AppKit and UIKit still developed and have access to all API that SwiftUI has.
Post reply on HN