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

501–510 of 579 posts

Re: Stop Making TUIs

#501

Post by MisterTea »

ricardobeat wrote: post #386

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…

> Hard disagree. Make more TUIs!

My big beef is the dichotomy of today's GPU accelerated bit-mapped displays which are burdened with this silly task of running a program that emulates a typewriter. Why TF do we not have a display protocol that can do graphics natively over SSH in 2026?

> TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input.

This assumes a typewriter emulator. Why are we not working on graphical systems where text is a first class primitive allowing us to easily draw text in any color, font, size, formatting and orientation as we please, onto a GPU accelerated display? Keyboard can still reign supreme. No mouse needed but if it is - first class support unlike crappy typewriter emulators.

Re: Stop Making TUIs

#502

Post by okanat »

hombre_fatal wrote: post #50
brainwad wrote: post #37

Earlier quoted context omitted.

Opening more than one instance is the default, developers have to actively work to block it. At least on desktop.

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

I don't know much about macOS. I only used other people's stuff and navigating it is really hard for me.

You're wrong about GTK, Qt, WinUI and Electron though. They default to "do nothing" which eliminates the ability to even know that another instance exists. You have to manually program that.

Re: Stop Making TUIs

#503

Post by okanat »

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

Earlier quoted context omitted.

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 rele…

> 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.

I don't know which GUIs you have programmed but for Windows and GNU/Linux this isn't the simplest option. It requires quite the effort to actually enforce single instance.

Re: Stop Making TUIs

#504

Post by VanTheBrand »

rererereferred wrote: post #441
63 wrote: post #436

Earlier quoted context omitted.

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?

We should get rid of ramps and handicapped parking at grocery stores too. If it’s such a large market someone can start their own accessible grocery store…

Re: Stop Making TUIs

#505

Post by utilize1808 »

MisterTea wrote: post #501
ricardobeat wrote: post #386

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…

> Hard disagree. Make more TUIs! My big beef is the dichotomy of today's GPU accelerated bit-mapped displays which are burdened with this silly task of running a program that emulates a typewriter. Why TF do we not have a display protocol that can do graphics natively over SSH in 2026? > TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. This assumes a typ…

> Why TF do we not have a display protocol that can do graphics natively over SSH in 2026?

Did you mean X server?

Re: Stop Making TUIs

#506

Post by scythe »

>Finally, I can think of one strong argument for TUIs: they’re cross-platform.

>[...]

>But remember: I’m not really building applications for other people to use. I’m building them for me.

Giant caveat to the whole argument and it's buried 80% of the way down. Granted, he alludes to that a little earlier, but if other people using your application are a completely irrelevant outcome, you're an unusual case.

I mean, sure, I make tiny one-offs, but those barely even have something you could call a CLI. I push as much complexity into command-line options and config files as possible.

Re: Stop Making TUIs

#507

Post by MisterTea »

misterderpie wrote: post #464
pjmlp wrote: post #459

Earlier quoted context omitted.

X Windows was invented on the 1980's and isn't the only way to graphically access remote systems. Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.

> Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data. Genuine question, what is your alternative suggestion to accessing lower level features then? A hard time I have with GUIs is that their input/output can't be piped. It's much more cumbersome to try to automate a GUI than to automate something in the terminal. Whilst I get that this is about TUIs, I do believe there is…

Look at Plan 9's devdraw. https://man.9front.org/3/draw

devdraw can be thought of as a 2D rendering engine. You load assets like text, bitmaps and so on then issue draw commands to render them. There is no SSH. Instead you connect to a remote machine and export resources served by your local machine including your keyboard, mouse and display, each of which is a network transparent microservice. The window manager, Rio (and others), multiplexes access to these microservices. You can run a graphical program without a window manager, e.g. you can boot right into Doom or the Acme editor. It's seamless and can run over any pipe that can push 9P including ssh. If you look at the Sam and Acme text editors you will find they are true modern TUI programs.

Shame we had a cloud ready OS for 35+ years and no one noticed. Instead were living in the 60's with GPU accelerated typewriter emulators.

Re: Stop Making TUIs

#508

Post by d-us-vb »

zahlman wrote: post #416
the__alchemist wrote: post #336

Earlier quoted context omitted.

> TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. Have you tried to write a GUI program lately? I suspect things may have changed. I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X. Basi…

> I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X. This is hard to square with the continuing obsession with Electron.

I suspect the u ubiquity of electron persists more because maintaining both web and desktop interfaces is somewhat simplified, and as a corollary, you don’t need a separate JS and C/C++/QML team. Qt has gotten pretty good, but JavaScript and typescript are easier to hire.

Re: Stop Making TUIs

#509

Post by [deleted] »

wormius wrote: post #475
bmitc wrote: post #403

Earlier quoted context omitted.

Terminal programs are GUIs. So you are using a GUI to access those remote systems. Thus, there's no reason why another GUI couldn't do the same. Everyone always acts like GUIs couldn't possibly make HTTP requests, interact over TCP or WebSockets, or do other remote communication. But they're actually, more often than not, more well suited for that than browsers for specific use cases, which are the use cases where yo…

I'll stick with plain old TTY Consoles, thank you.

[deleted]

Re: Stop Making TUIs

#510

Post by hooch »

mihaic wrote: post #393

The people that keep arguing for TUIs for everything seem like religious fundamentalists that can't be convinced with any argument that user interfaces should be about the user, and need to adapt to the task at hand. Every time I use Claude Code, I'm wondering why the hell I'm regressing to the level of a machine. I paste an image that I want fixed, and I don't see the preview of it. I can't cut or edit text somewher…

Sounds like you ought to try Claude Desktop.
Post reply on HN