Stop Making TUIs • Hacker News Board

Re: Stop Making TUIs

#551

Post by yencabulator » Sun, Aug 23, 2026, 8:49 PM UTC

MereInterest wrote: post #240

MintPaw wrote: post #121

Earlier quoted context omitted.

Why would this be true? The way "single instance mode" usually works is by taking a global mutex or making a lock file. What makes this not possible for TUI apps? Isn't it just culture?

My guess is that is because a TUI can’t give focus to the existing instance. When a GUI application realizes that an instance is already running, it can ask the windowing manager to unhide and focus the running instance. For a TUI to do the same, it wouldn’t just need to find and focus the window, but would need to trace it through the myriad ways that a TUI can be displayed. I may run a TUI inside a docker container…

> a TUI can’t give focus to the existing instance

Emacs Server and tmux would both like a word. Make the current tty show the app output.

Re: Stop Making TUIs

#552

Post by yencabulator » Sun, Aug 23, 2026, 8:51 PM UTC

hombre_fatal wrote: post #113

underdeserver wrote: post #67

Earlier quoted context omitted.

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.

`waypipe ssh HOST COMMAND` is darn simple.

Re: Stop Making TUIs

#553

Post by bionade24 » Sun, Aug 23, 2026, 8:56 PM UTC

d-us-vb wrote: post #508

zahlman wrote: post #416

Earlier quoted context omitted.

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

QML is a Javascript Superset

Re: Stop Making TUIs

#554

Post by JoshTriplett » Sun, Aug 23, 2026, 9:13 PM UTC

eviks wrote: post #247

JoshTriplett wrote: post #10

You know what's awesome about TUIs? They live in a tab in my terminal. 95% of the time, my system has three windows open: terminal, browser, Signal. Please, make more TUIs and web apps, so they can live in my terminal or my browser.

> They live in a tab in my terminal. So you can't even immediately switch to your app and don't see it in an OS-integrated list?

I can see all of my tabs at a glance, their titles indicate what's running in them, and I can easily and quickly switch to them with the keyboard.

Re: Stop Making TUIs

#555

Post by 0x457 » Sun, Aug 23, 2026, 9:21 PM UTC

worthless-trash wrote: post #540

0x457 wrote: post #117

Earlier quoted context omitted.

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.

you miss the point entirely bro.

The point is a realease every N years with overlapping year(s) of support is too fast for some?

Re: Stop Making TUIs

#556

Post by Gormo » Sun, Aug 23, 2026, 9:23 PM UTC

frou_dh wrote: post #478

Gormo wrote: post #457

Earlier quoted context omitted.

Perhaps the average TUI fan is someone who correctly recognizes the negligible relevance of typography in optimizing their computing workflows, and prefers monospace fonts for purely functional reasons, which naturally take precedence over merely aesthetic concerns when working with functional tools. The total abandonment of the form-follows-function principle on the part of purely visual designers, who worry about w…

You can't dismiss typography as irrelevant and trivial aesthetics. It's a whole field encompassing many things including legibility to humans. There's nothing more "functional" than principled crafting of legibility for each UI element. And no, a crude "Just use the same font in a single size for everything" approach is not the endgame for legibility. Just because there have been some crappy industry trends doesn't m…

> You can't dismiss typography as irrelevant and trivial aesthetic.

Sure I can. That's not to say that it's completely useless and not worthy of any attention at all, just that it is far removed from the primary considerations of software design -- it absolutely is an aesthetic matter that is not an important consideration until functional design is settled.

Re: Stop Making TUIs

#557

Post by bmitc » Sun, Aug 23, 2026, 10:08 PM UTC

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.

Okay?

Re: Stop Making TUIs

#558

Post by joshka » Sun, Aug 23, 2026, 11:07 PM UTC

torginus wrote: post #500

joshka wrote: post #484

Earlier quoted context omitted.

The problem succinctly is when the terminal emulator only sees cell values and instructions it can't do anything more with things. Two really good examples are implementing accessibility well, and scrolling / changing things above the terminal pane without rewriting the whole history.

What you describe sounds a lot like the HTML/CSS split, with having a separate semantic/display data. I think that's a rather large jump from the 80x25 model, retrofitting that much data sounds like quite the challange. Not sure how you're planning on doing that, can you incrementally extend the current model, or will it require a completely new protocol?

New protocol entirely. The existing stuff is too baked as having positioning, movement, cells as the unit of abstraction. You need to have that available, but not as the core abstraction level. The core has to be areas, words, layout, etc. Not: "move to 20, 35, start red, bold, print border characters"

Re: Stop Making TUIs

#559

Post by joshka » Sun, Aug 23, 2026, 11:15 PM UTC

quantumwannabe wrote: post #445

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

Codex uses Ratatui also since June last year. You might be interested to read https://github.com/openai/codex/issues/8344

There's a lot of things you can do to get to 90-95% fidelity with a normal scollable terminal, but that last 5-10% is impossible. And it's because the you're throwing away a bunch of information about mouse movements, clicks, scrolling, keyboard on the input side and all the layout info on the output side (the terminal just sees cells, locations, etc.).

A good analogy is what if your webserver could only send pixels, not html. And receive raw mouse movements. The amount of stuff you have to do to reconcile that across operating systems and hardware would be enormous. That's what you realistically have when you're writing a tool that reimplements all the bits from a terminal emulator in a tui.

Re: Stop Making TUIs

#560

Post by cadamsdotcom » Sun, Aug 23, 2026, 11:40 PM UTC

TUIs are better for typing centric keyboard workflows; GUIs are better for keyboard shortcut centric. Your desire UX will guide you.

People don't expect to be primarily typing into a GUI; they expect to occasionally click something interesting; have things pop into view as they happen, etc.

A TUI's advantage comes partly from imposing a constraint: how can we make close to all the user does in this thing and make it doable by typing at this cursor?

As always it's horses for courses.