Hacker News Reader

Comment by Surac | Hacker News Reader

TUI is a kind of self defense. big corps create and kill gui frameworks faster that one can learn them. Browser based ui is a real waste of resources (and also evolve in a absurd pace). The Console is a last resort to write small (understandable) gui that work on many platforms.

View on HN

Are the TUI apps built on TUI frameworks? Do the TUI frameworks last longer than the gui frameworks you mentioned being quickly killed by "big corps"? In the Windows space, WinForms, WPF, WinUI are likely the biggest examples of gui frameworks, especially from "big corps"; they've been around for decade(s) and have not been abandoned (/ they continue to be supported) - how do TUI frameworks compare? On the other hand, TUIs may be better for things like running over SSH, and for cross-platform compatibility - important, yes. Although for x-platform, things like Avalonia or Uno could be better comparisons?

Curses, the TUI library, has been around since 1978. It was superseded by ncurses in 1993, which saw it's latest update in December of 2025. Both of them still work and can be used today, with the caveat that the official original curses has been deprecated since 95, but NetBSD maintains an updated version iirc.

They generally stay supported, or if not supported, working.

I like browser-based UI, as they offer similar advantages to TUIs: You can use the UI on a different machine than the application itself is running. Arguably, modern Web standards also lend themselves to some elegant code design for UI. However, the "waste" is a valid point, but then again your TUI (and many GUIs) will fail on those things that cause the "bloat" of a browser: support for the weirdest encodings, dealing with the most absurd edge cases, supporting the largest amount of devices in a uniform manner. Shipping a whole electron for your crappy app is not what I mean. This should stop, as it trades all advantages for almost only disadvantages.

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 work around that problem, but that arguement nullifies everything, since you can run/write/execute anything in a turing complete system, if you complain you're just not dedicated enough.

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.

Carbon and Cocoa changed a bunch of times, also React actually makes sense even though it also changed

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?

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.

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.

"AppKit and UIKit still developed and have access to all API that SwiftUI has."

No they don't. Many components are SwiftUI only.

We're in an era where soon (if not already) it will become straight forward to direct a clanker to move an application from one gui framework to another.

Once we have robust automated computer use, that becomes the verification loop, and this problem will almost surely get solved.

Reply on news.ycombinator.com