5 ms·
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
by Surac 27d ago
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.
- 0x457 27d agoHuh? 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?
- worthless-trash 27d agogtk1/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.
- 0x457 26d agoCarbon 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.
- worthless-trash 24d agoyou miss the point entirely bro.
- 0x457 24d agoThe point is a realease every N years with overlapping year(s) of support is too fast for some?
- frollogaston 24d agoCarbon and Cocoa changed a bunch of times, also React actually makes sense even though it also changed
- throw83949390 27d agoWhat 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!
- 0x457 26d agoThere 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.
- Shank 26d agoApple believes SwiftUI is the future, not AppKit and UIKit/Cocoa.
- 0x457 26d agoSure, 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.
- lenkite 25d ago"AppKit and UIKit still developed and have access to all API that SwiftUI has." No they don't. Many components are SwiftUI only.
- underdeserver 27d agoThey generally stay supported, or if not supported, working.
- ssivark 27d agoWe'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.
- no-name-here 26d agoAre 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?
- cbarnes99 26d agoCurses, 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.
- fp64 25d agoI 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.