Why TUIs are back(wiki.alcidesfonseca.com) |
Why TUIs are back(wiki.alcidesfonseca.com) |
TUI are snappy, accessible over ssh, small screen friendly, easily embeddable in zellij or other multiplexers, easy to copy paste from... Amazing.
The current implementation isn't command-line, but a re-implemented GUI in disguise, awkward and even more buggy. Why should I use that over a GUI? I would prefer Electron over those TUI unless I have to SSH.
For the past few weeks I've been wrapping up Booba [1], which is developer tooling to combine BubbleTea and Ghostty in WASM deployments (using ghostty-web).
It provides for some interesting deployment patterns both locally, over network, and embedded in a web page. It's intended to be very easy to adopt; at the simplest, one just changes `tea.NewProgram` to `booba.NewProgram`.
I used Booba to make a demo page [2] for our NTCharts TUI library published to GitHub Pages. The repo READMEs have GIFs... this page is all embedded WASM.
There's also new Kitty-Graphics-supported widgets in there (picture, chartpicture); I updated Booba and Ghostty-Web to support it. Still getting the kinks out.
[1] https://github.com/NimbleMarkets/go-booba
[2] https://nimblemarkets.github.io/ntcharts/demos/heatpicture-p...
It's not too bad to theme GTK apps and have them all look a consistent way. For example I use Tokyonight Moon and Gruvbox and they both have GTK themes that look great for Firefox, Thunar, GIMP, LibreOffice and more. I don't use Omarchy but here's a few screenshots https://x.com/nickjanetakis/status/2037125261657883061/photo....
Nothing fancy was done on my end, just installed the specific GTK themes. They even support live reloading because GTK's tooling supports it, my dotfiles at https://github.com/nickjj/dotfiles handle all of it for you. I still prefer TUIs but you can have nice looking GUI apps for when you want them.
- Firefox: Uses its own custom rendering engine but interfaces with GTK3. It respects standard GTK3 themes.
- Thunar: Uses GTK3
- GIMP: Since v3.0, they now use GTK3
- LibreOffice: Uses its own visual framework (VCL) but has a GTK3 plugin to draw its window frame and menus, and it also respects the system theme.
None of these use libadwaita, let alone GTK4, so they're not good examples unfortunately.
They're some of the most popular GTK apps available. They seems like a good example to me.
The themes I'm using are compatible with GTK4 apps too.
I use niri which suggests installing xdg-desktop-portal-gnome which comes with Nautilus which is a GTK4 app. It's perfectly themed just like the GTK3 apps.
I get more things done, in most cases, than via a GUI. In a way a TUI is a GUI of course, but with the focus on keyboard use and inputting instructions/commands. Most GUIs seem to be centered around keyboard AND mouse and then try to make things convenient here for those operations, such as drag-and-drop via the mouse.
For me what makes a software usable in the long run (after initial learn) is shortcuts and keyboard navigability. Old GUI frameworks had built-in features for this (app-wide shortcuts, underlined letters, etc.). The web has haphazardly copied one of them (“accesskey” attribute), but now this has been completely forgotten. None of the major websites have accesskeys, even for the most frequently used element like the search bar. There are no shortcuts for frequently used functions such as “like”, “reply”, what have you. It's like developers have universally forgotten that the keyboard exists and what it can do.
TUIs don't solve that.
In a way AI agents are validating what us old-timers always knew: the CLI and TUIs is the most powerful way. And AI tools didn't choose the most common dev environment: devs using fat IDEs (and btw I was already using IntelliJ IDEA back when some people were still arguing NetBeans was better than IntelliJ) are way more common than those piping Unix commands to achieve even simple tasks. Instead AI tools did choose the most powerful way to work: and that's piping terminal commands and SSH/tmux/TUIs.
When the tool itself, like Claude Code CLI, is immediately showing the outputs of piped Unix commands and allowing to run commands from a prompt and is, itself, a TUI, it's validating that it's an extremely powerful way to work.
A Claude Code CLI (or similar) TUI in a tmux session is something quite powerful.
Then you combine that with the fact that techs like LSP and tree-sitter did at least partially commodotize the IDE and suddenly TUIs (or things very close to it, like GUI Emacs: which can do graphics but is still mostly used as a TUI tool) do look very appealing.
Magit is considered by many --even non Emacs user-- as the best Git interface ever. It's text, text and more text.
My life is terminals (text), Git and Magit (text), Emacs (GUI but basically text), SSH (text), tmux (text), many text things I forgot and now TUI harnesses.
If you're modelizing in Blender or editing movies or creating movies, a GUI makes sense. But if you write code, which is text, all you need is text, text and more text.
TUIs are making a comeback because it is all text and AI agents are proof of that.
I get your point, it does feel like there's something different, but I'd suggest that there is no black and white line, instead there's a spectrum, with fully native local UI at one end and fully declarative remote GUI at the other end. HTML and the web exist somewhere towards the latter.
There have been many attempts at points all the way along that line though, and every point comes with trade-offs. Performance degrades, OS-native components are eschewed, programming gets higher level, etc.
If you have python installed, you can start a web server with a couple lines of shell script. Is there any really good truly lightweight webserver? (Something under 256KB)
I would say the optimal UI is a Keyboard driven normal Desktop app. An app that can take full advantage of graphics elements of a desktop app but is lightning fast to interact with thanks to that it's keyboard driven. Very few people build apps like that though. Sure there are keyboard hints in many apps but they are usually not 100% guaranteed to cover all cases and are sometimes an afterthought.
It's by far not as beautiful rendered as the native OS layers, but easy to navigate and a good foundation for cross platform GUI development. And I got it even approved for the MacOS app store. Here's my write up: https://marchildmann.com/blog/imgui-mac-app-store/
Asking honestly, because none of the ones I use is.
The install base would be huge, and it's a solid cross-platform option.
A reasonable TUI can be built without any design or frontend people even looped in.
Collaboration and coordination tend to slow down processes and flatten outputs.
Even in the PC world, the move from DOS based TUI programs to windows GUI in applications like POS was not without some user trauma and insatisfaction.
I was vibe coding a layer on top of textual last week that allows me to plug in both interactive and information display Python functions into a TUI grid. Really simple stuff, with textual doing the heavy lifting.
For people who don't know this version of TUI, it's the ole, "Press 1 for X, Press 2 for Y" kind of interfaces that you use over a phone. Think voicemail text-to-speech and automated speech recognition.
I think this is the primary reason. I feel like whether or not there are good native libraries things were bound to converge into cross-platform preferencing since it's cheaper to produce and maintain.
Seems like it could have gone differently. Feels like the time could be ripe for something like a "declarative gui spec."
A GUI is a huge regression here.
TUIs are popular because once you use a piece of software that doesn't have a poorly-written GUI library full of animations bogging it down, you don't want to go back.
It's hard to make a TUI that isn't snappy, no matter how much useless eye-candy it has.
I'm pretty sure the success has nothing to do with the TUI though. I personally enjoy it a lot but the productivity boast doesn't come from avoiding the mouse.
I don't know about everyone else, but the code I reviewed as a Junior was high quality code I was expected to learn from. That's entirely different from doing code review on whatever CC outputs.
Can someone who is more knowledgeable about these help compare and contrast these three texts a bit?
Are you saying GUI "the real deal"?
In contrast, most TUI toolkits generally require the developer to wire things up manually. Maximum developer flexibility, but with a decent learning curve. Having an LLM available to handle the initial wiring definitely speeds things up.
I know I had a few long lasting bugs with a TUI I wrote years ago that Claude was able to find the fix for pretty quickly. These were bugs that weren’t obvious to me, partially due to the arcane nature of working within a TUI.
I am affected by it also and have always been fond of TUIs in a nostalgic way.
But that's changed drastically in the last few months. I spent the weekend doing SwiftUI stuff with Claude, with a lot of success. It's going to get much easier to ship fast, solid, native UIs for things, and native UI is both very fun to build and also attractive to ordinary users.
(Fun green field for doing interesting UI work: do native UI for remote server stuff, like an htop UI that uses some dialect of SSH to fetch remote data.)
I think modern TUIs are a blip. A big, important blip. But a blip. The age of the Orc is over. The time of the Human Interface Guideline has come.
I mean, I guess that's more or less just a summary of the blog post, but it's true. And it will remain true until the fragmentation ends, and the fragmentation won't end until Microsoft gets its act together and ships their version of SwiftUI so that some sort of abstraction layer over SwiftUI/GTK/MsftUI can be created. And since Microsoft will almost certainly never get its act together, the problem will remain.
In other words, not a blip. The UIs of the present and future will all be Electron apps and TUIs.
I am, in a proverbial sense, buying puts on Electron.
JS literally destroyed the software landscape. All the bad practices advertised as best.
The biggest current reason is fashion. Tools like Claude Code did it, and while they actually had good reasons to run in the terminal, the tools' popularity and wildly different look, especially to non-terminal-native users became a signal of some positive sort.
I don't believe that any of the rationale posed in the article is a popular reason developers are using.
Maybe I'm mis-perceiving - but that's the impression the flutter.dev site gives people.
I've no idea what you mean regarding: "rather than exemplifying its flexibility and adaptability to _your_ platform, programming language etc".
It can produced mobile, web, or desktop apps from the same codebase... Dart and flutter are open source projects supported by Google, like android and go lang.
Seems like you're looking for excuses not to use dart/flutter. That's fine but you could just say you don't want to use them.
Well, that's already a strong barrier to its use. When creating a GUI for an app, the toolkit must offer bindings for the language you're using, it's not you that needs to learn a bespoke language just to use the toolkit.
> It can produced mobile, web, or desktop apps from the same codebase...
That's the thing - not really. It seems it can produce a web or a mobile app while will _run_ on the desktop. But mobile and web apps do _not_ work as desktop apps, nor the other way around; the whole UI/UX language is different... even if some companies try to foist mobile apps onto desktop users.
> That's the thing - not really.
If you were to spend some time learning dart and flutter you'd know this to be false. But I'm not here to change you mind as you've already made it.
- You can make Wine apps inherit the system theme, well, at least the colors. Although it will still look out of place, but it's not much different to the issues with running a Qt app in GNOME, or a GTK app in KDE. Wine in this case can be considered as just another UI toolkit that has the same problem that all UI toolkits have in Linux.
- Finally, the resource overhead of Wine is far, far lesser compared to Electron, which is a basically packing in a full-fledged browser.
Failing projects over bad UI teaches fear, not design. Good interfaces come from iteration and feedback - which is exactly what user-centered design is about
Dumb question and slightly off topic, but is there a reason why so many AI tools are CLIs … as opposed to just an API or another interface?
I feel like I’m missing the obvious in why there feels like an explosion of CLI tools lately, related to AI.
I think it's important to note this because it's not great. Either I'm having a fever dream, or, someone will GUI this stuff and it'll be a gamechanger.
Don’t fall for this.
Interact as needed, matrix screen saver when idle to prevent burn in.
I don’t see terminal apps as heavy at all…
How to make them a wallpaper thats interactive I wonder…?
Funny if I just search it… PlashApp by Sinde, Set to Termix docker and BOOM :)
I've been reverting more and more: mutt (mail), newsboat (RSS), amfora (gemini protocol), gurk (Signal), chawan (web), and even trn (Usenet). My RAM usage is tiny. Everything is quick.
GUIs should take a page from the TUI playbook and consider making the app keyboard-first. Nothing is more frustrating than a missing hotkey.
It seems that barely anyone thinks about what GUI should like for app you use hours at a time for days at end.
About only software that's half decent for it are IDEs (and probably some industry-specific niche software I'm ignorant of)
I don't know about that. The Gemini TUI takes like four full seconds to start on my machine. I have no idea what the hell it's doing. A lot of the fancy new TUIs that are coming on the crest of the current fad are hot garbage. I hate them.
if TUIs were truly back - as DHH would like you to believe - his money maker - Basecamp - would be available as a TUI, Salesforce, Workday, Bloomberg etc would be available as TUIs. Though Bloomberg is the closest to a TUI.
but let's continue to delude ourselves.
Nobody here (especially top comments) seems to mention this.
Very low on the actual information side.
Citation needed?
Does it also follow that we can have pretty much any shape for valuable apps? API, CLI, TUI, Web, SwiftUI, WinUI...
In the "before times" an API and web UI that double times as native via Electron was the biggest bang for your buck.
CLI would be a hacker's side project, TUI would be them showing off more. Native would require hiring a team of specialists which is a total non-starter.
In the "after times" API and CLI are getting more love rebranded as MCP and tools.
To the parent topic, I suspect "build a TUI around my CLI" is a slam dunk for an LLM text in / text out machine which is why there is a resurgence of these too.
Hopefully that is the gateway drug to "build a SwiftUI around this", and an antidote to doing everything in Electron.
Even in a world of agents, less code = better code.
I don't think its all a house of cards; LLMs are real technology with real utility, in coding and lots of other domains.
They are also massively and unsustainably subsidized for certain uses (and the increasing crackdowns on repurposing the subsidized services for other uses should make it clear to anyone that the subsidies are unsustainable, and that there is a very clear focus on owning certain markets before when the music stops motivating them.)
What originally got me excited to build TUIs was the concept of delivering apps over the wire via SSH. SSH apps resemble a browser in that way: no local installs required.
It's a major reason why I enjoy hacking on https://pico.sh -- deploying the TUI requires zero user involvement.
I think the main driver was frameworks, available for a range of languages, that make it easy to create nice-looking TUIs (ratatui, textual, ink, etc.)
My bet would be a desire to do away with heavy browser based UI and the curiosity of trying to test the limits of terminal based rendering.
It's a shame that a serial port typewriter emulator has somehow managed to stay alive. Instead of building new and exciting system based on new and exciting technology we get GPU accelerated typewriter emulators. It's a weird form of tech blindness mixed with nostalgia. Why arent we moving on? ssh? You can pipe whatever protocol over ssh.
I would really prefer if we moved on and worked on drawing to remote bit mapped displays. We have examples to learn from: X windows was network transparent though not a well thought out design (see audio.) Plan 9 has devdraw, an rpc based rendering engine that you load assets into then issue draw commands over the wire from a remote graphics program.
We see this today - there are plenty of protocols to support rendering applications over the wire (vnc, rdp, x-forwarding, waypipe, broadway, etc...)
They get very, very little usage outside of highly technical spaces. The demand just isn't there.
What did get there was the browser - which solved this problem quite nicely for basically every desired use-case, and has the benefit of offloading most of the computation to the remote device.
---
And as an aside - text remains a wonderful medium, with an incredible amount of composition and flexibility. The issue with GUI systems is that output != input. And it turns out that matters quite a bit, and is unavoidably limiting.
[0] https://zed.dev/docs/remote-development [1] https://code.visualstudio.com/docs/remote/ssh
Do you mean that TUIs are popular because everyone is now trying to imitate Claude Code? or because TUIs are now easier to develop when Claude Code exists?
CC demonstrated that one can have a powerful, flexible and responsive interface in a terminal, and to have that for a piece of software that has wide mass market appeal. I don't think we've seen this since WP5.1 . (Personal opinion: the CC terminal application beats their desktop software hands down in usability. That said, the desktop software is a lot better for corporate email trawls and helping to iterate on visualisations.)
Then for prospective devs, CC makes it easy to sling (and debug!) code that handles the various terminal vagaries with much less headache. No need to care about manually maintaining control code state machines; no worries about a missed SIGWINCH handler screwing up your in-window layout on resize or font size change; much easier integration with available CLI tools.
I have written some ncurses/C code in my time. I wouldn't want to do that by hand again.
It's also nice to have a little less to worry about as a desktop application developer, to be honest. The display is less nice (low text density especially) in exchange.
This echoes my main interest in TUIs. Otherwise, I greatly prefer a good desktop application.
There's not a single good universal UI. The best is the browser and it is reasonably successful but the sandbox makes it specifically unsuitable / high friction for doing things that need local access to files, network, etc. And it is ridiculously high overhead if you just want to run something simple. Then remote access is even more a debacle. Can I access an application running on my windows host from my Mac? can I forward that through a tunneled connection?
TUI is a simple, universal protocol that does what you need and is natively remote. Whatever I use locally will seamlessly work over an SSH connection.
And it's a big middle finger to the OS vendors who thought locking everyone in by making everything incompatible or ecosystem specific was a winning strategy.
* Are simple to grasp for uses * Efficient to use (not just resource wise) * Look nice on nice terminals
Notcurses (C++) and Ratatui (Rust) did help ncurses (C) a lot.
The only hard part about vim is to be forced to strecth the finger up to Escape for what is essentially the most essential function in a modal editor: Going back to command mode. The ideal workflow is do a quick edit and go back to command ("normal") mode instantly. The fact that Escape is used is a historical artifact that needs to be called out.
So just remap CapsLock to escape, it system-wide, it's not that hard and it's nice to have Escape there generally. In Linux and MacOS it's just a GUI setting away and in windows you just have to edit (create?) a registry key. Can be done on any machine under a minute.
Apart from that I don't see where the learning curve is since you can just start with the basics from vim-tutor and look up for more when you feel you're spending too much time on something. I already felt faster than in any other editor when I just knew the basics. The real problem of vim is that you get used to modal editing very quickly and it feels like the stone age when you don't have it.
I live on the CLI, I have one a hotkey away, but please, technology has advanced significantly since the terminal was the only option, and we have far better options for building UIs now.
This whole TUI thing just seems like a fashion trend.
It's just a shame that we don't have a great cross-platform, streamed, UI system. The web is great in it's own ways, but clearly something could be a lot better for this purpose. Flutter's ok, but not on-demand enough and too married to Dart.
OpenCode for example has not yet figured out "maintain a log of all messages and send that log to the SSE endpoint in the same order to get the next response" and has regular prompt cache misses even with context pruning disabled
With that background, most TUIs are really two steps back compared to a decent GUI. (Wild west navigation/hotekeys, broken copy and paste, lack of integration with the environment, just to name a few.)
The core of the problem is IMHO, that we really lack a decent cross platform GUI platform, which is really integrated into a programming language or part of the standard library.
Outside of Swing (which lacks access to a native browser element), we have Tk (no browser component, no drag'n'drop, at least from Tkinter), wxWidgets (seems that the community is very small and especially its bindings needed to be resurrected at least once), Qt with the ever looming possibility that it will get deshittified to make more money (... and no, KDE is not that important and I doubt the KDE community could take care of a fork long term).
Which leaves us with Electron or the other variants of 'browser component + JavaScript/CSS and callbacks to a local server, which is a really bad programming model (ignoring the memory/runtime overhead for even trivial applications).
The problem is, to build a decent cross platform gui toolkit, one needs a lot of funding and a lot of people (usability, accessibility, design, documentation, testing...). The open source community didn't manage to pull this off (GTK is by now for all practical purposes Linux only) and there is no modern contender for Qt or Swing (with their own problems).
TUIs are no solution to the core problem (and it would be absolutely possible to have a GUI toolkit with a TUI renderer for perhaps 80% of GUI needs), but I understand every developer who chooses TUIs for cross platform UIs given the alternatives.
- No distractions from visual content
- Extreme efficiency with keyboard
- AIs can code them up quickly. It used to be a total pain
As far my opinion goes, this is biggest (and really only) reason.
Oh we need multiple windows we can move around/resize? Let's make them text windows. We want people to be able to quickly select options? Yeah make those text boxes. We want to quickly compose documents with some kinda style/formatting? Yeah they'll need to write more text to format it (but let's not make any apps to easily view the text in formatted mode).
It’s allowed. You don’t have to use them.
[0] https://github.com/rothgar/awesome-tuis
[1] https://terminaltrove.com/explore/
[2] https://github.com/ibraheemdev/modern-unix
Even before Claude Code, I always see htop as the prime example of a good TUI.
I don’t know if TUIs will be the answer, but it’s an interesting development!
Also, the explosion of new languages in recent years means having to write a new set of FFI wrappers around existing libraries, and it's easier to make an idiomatic library for TUI development than wrap all of GTK+ or Qt.
Running TUI apps over SSH isn't ceremony-less either — you have to set up SSH keys and copy your public key over into the remote end's authorized_keys file — but it's ceremony that you would have already had to do anyway to get access to the remote computer in the first place. And once that ceremony is done, you can now run any TUI (that the remote computer has installed) remotely without any more ceremony.
I don’t need pretty buttons, I need usability and readability. Without having a 50” display!
To avoid context-switching from the command-line, many essential UIs were made text-only. Another route would have been to integrate the command-line within graphical applications, but few did it -- the main example that comes to mind is Jupyter.
There are quite a few GUIs that can be navigated with keyboard, e.g. menu bars can usually be activated with alt or win and single key presses
Lucky you. I avoid electron apps because I'm limping along with 16gb.
We made our machines 100x faster and instead of running compute locally we just made 100x slower client software.
People now have access to good terminal emulators. Back in the day, you had cmd.exe in Windows. Now you have a plethora of Linux/Unix terminal emulators, Terminal.app in MacOS, and Windows Terminal in Windows 10/11. These are quite capable applications able to render good, complex text-based interfaces.
So we created tooling we know on the CLI.
Every person here that thinks its AI that caused the resurgence of CLI tools is a vibe coder who just entered the scene this year.
HOW? The TUI library should handle everything for you. So HOW do... Wait. Did Claude vibe-code up its own set of TUI routines instead of using a library?
Embracing constraints and "how it works" used to be at the core of their software ethos.
When I end up helping other devs and use their non vim setups...now that really trips me up. Capitals everywhere, random hjkls ... I have to really slow myself down when using a "normal" editor.
This is why I love JIS, even though I don't actually need the Japanese keys. That small spacebar is so much better, and you get three extra keys (Henkan, Muhenkan and Kana) along the bottom row. As an Emacs user, I bind Henkan and Muhenkan to be Control keys. It's very comfortable.
Also ctrl + [ is standard terminal/ascii for esc so that might be a bit more ergonomic than reaching for esc
Ctrl + [ would be acceptable if it wasn't, imo, the most important function of the editor.
EDIT: My bad, you can do it with Glide apparently
I agree, too, besides reminding myself to use numbers before movement commands there was really nothing that felt super hard about vim. It almost disappointed me, I always heard the jokes about not being able to quit it!
To be fair I mostly use `/` + (n/N) + Enter with `incsearch` on (by default in nvim), I feel it's really the superior way to move around and it has deprecated a lot of my vim-fu.
In the same way, apart from occasinal `ciw` (or other text-objects), I do most of my edits with `:s/old/new`. I don't even use a complicated regex as sometimes it's just easier to write one or two simpler ones. It's just faster to not have to go to a specific location before you make an edit.
I still don't understand why people keep mentioning this, ctrl-c works as well to go back to the normal mode.
> windows you just have to edit (create?) a registry key
Or use Powertoys, which I don't know why it isn't a setting.
(saying as a Mac, Linux and Emacs user, although I still use Vim in the terminal)
Also just to be pedantic: https://stackoverflow.com/a/5036294/10469162
Right here:
> modal editor
They want a GUI, but, instead, they have to resort to something like this. A GUI in a TUI.
They want something portable. They want something that can run remotely. They want something they can run more safely than having to expose a socket. They don't want to have to bring up an entire desktop.
Rootless windows are effectively dead. That leaves web interfaces (and all of their issues) or doing a TUI, where all you need is an SSH connection that everyone already has.
In the past you could slap something together with Tcl/Tk, and just launch the window over X Windows. That's not so easy today, and no one is running remote X anyway.
The LCD is SSH, and these are the only things that fit.
I was quite recently, but even then remote X is missing a really big usability piece: keeping a long-running application open on the host and periodically connecting to it from a remote node (concretely: connecting to my server from my laptop). VNC/RDP/etc all do this at the desktop level, but they're pretty mediocre experience-wise.
tmux gives me this for terminal applications without really any compromises. I run tmux for local terminals as well as remote terminals; the hotkeys are all deep muscle memory at this point. It just works.
If you:
1. Have a low-latency connection to a decent machine, and 2. Are on a machine that's weak, or isn't yours, or that you don't fully control (e.g. employer forces you to run Windows)
... then you live in remote X apps my friend.
Sixels are supported by many terminals[0] (several of the terminals mentioned that do not support them are based on GNOME VTE for which support is in the works and, based on the bug tracker comments, it seems to be almost done).
This includes xterm which is probably the most "standard terminal" on X11 you can get.
Because it's easy to get things done for a TUI, but if I create a proper GUI, my codebase is suddenly more complex. And it's not like there's a solid, reliable GUI toolkit that I can use, they're all riddled with different bugs and caveats.
> Flutter's ok
If you ignore the absolute nightmare that is building applications in Flutter. Even Flutter itself isn't really designed to be compiled by anyone (although, in practice, your distro will shield you from this issue).
It's called the web/Jupyter. And no, web-driven UI doesn't have to be heavyweight either, any more than HN is.
My motivation is avoiding all the piles and piles of extra software dependencies that X and/or Wayland bring in.
In addition (but might only be relevant in my niche platform) is that Wayland is buggy and X is deprecated and unmaintained making making the GUI work there a constant struggle.
Time will tell if it is an improvement
But if I want to, say, develop the app for Windows. That is easy. You get a tiny binary to just opens a form and runs with a double click. No install necessary.
The same thing on Linux? Impossible. There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained you need to ship the entire OS. Now your file size is huge. I can't use Python, because now Windows users need to have Python or I have to ship an interpreter.
The only plausible alternative is something like Java. Now you have a single .jar file that runs on any system. But then Oracle changed the license, and JavaFX is no longer part of Java (Swing still is).
Honestly, I just want to display a menubar with keyboard shortcuts. Why can't there be a menubar VM or something that gives me access to a menubar on all OS's without having to deal with all of this. We are already shipping the entire browser with Electron. That is stupid. The way it should work is users install a something like Flash but for desktop apps and every app just uses that platform.
It's probably easier to ship a DOS game than a desktop app because everyone who wants to run a DOS game will just have a DOS emulator installed.
This will run on Windows, Linux, MacOS, and Tcl's starkit/starpack system makes it easy to generate a single executable file for each OS that can just be copied over and run without any installation needed.
So don't be self-contained. I mean, you depend on an X server or Wayland, right? So why not depend on GTK or Qt being available?
(Of course, it _is_ tricky to be able to depend on any of several versions of these, but still.)
I’m not sure if Google actually already gave up on Fuchsia, I’d be surprised if the work actually stopped, but it’s clear now that it will not be a panacea and if it will ever get released and gets some traction, it’s still like a decade away from becoming a major OS.
It's basically like building a website with div and basic CSS.
gpui-component exists: https://github.com/longbridge/gpui-component
Up until sometime late 2025 GPUI wasn't even on crates.io, and it seems like the GPUI-component ecosystem still promotes using git deps. It was also in "read the code for docs" state for a very long time
It's been a while since I've used it, but there were weird things missing too like the Scollbar was located in Zed's UI component crates instead of core GPUI. Arbitrary text selection also is not possible, which is something I really value about egui.
What we need is a framework that is easy to use, cross platform, open source, and ideally can be used from your programming language of choice.
There's at least Qt, GTK, umm, and, I guess Juce and wxWindows, right? Oh, I see there are more:
https://en.wikipedia.org/wiki/List_of_platform-independent_G...
Can you explain what's deficient about the first two I mentioned?
That's one word that should never been used in an design meeting. None of the GUI I've used has managed to do this right. Even Emacs and Firefox. The platform are totally different (and in the case of Linux/Unix, there's a lot of different HIG competing). So trying to be cross platform is a good illustration of the lesson in https://xkcd.com/927/
The best bet should be a core with the domain with a UI shell. And then you swap the shell according to the platform.
I think it is more of a staffing problem. Plenty of people know web development, so you want to use those people for desktop as well. Having desktop be JS (electron) helps a lot with that.
Not a programming language, but the programming language: C. The toolkit needs to be available as a C API because that lets it a) provide stable API and ABI and b) provide bindings for multiple other languages without having to jump through hoops, especially for other compiled languages (binding Qt to Python might be easy, but bindings to something like, e.g. Free Pascal requires an intermediate C++ library that exposes a C API that itself can be used from Free Pascal - and applications need to distribute it that library too).
Unfortunately the vast majority of GUI toolkits are not writtne in C but in C++ or some other language that makes using them from anything than the developers' favorite language a pain. And really the only mainstream that is written in C is GTK which has a complete disregard for proper backwards compatibility.
(you may think that a library only needs to expose a C API but it can be written in any language, however for something that doesn't have any widespread availability, you may want to link to it statically - however that can be an issue with anything outside C/C++ - as an example i recently tried to make a FLTK backend[0] for Lazarus since FLTK is a C++ library that the devs encourage to link it statically and it would allow creating GUI programs that are self-contained binaries... but statically linking a C++ library -for which i had to first make a C wrapper- in a non-C/C++ turns out to be a PITA under Linux if you are not g++ as that does passes a bunch of magic flags to the linker and impossible under Windows - or at least msys2, so i gave up).
I like, that you also added backwards compatibility and ABI stability, two very important and valid points. There is to this day the joke, that the best way to write a binary GUI app for Linux is to target the Win32 API and run it via Wine, if you care for a stable platform. ;-)
> wxWidgets (seems that the community is very small and especially its bindings needed to be resurrected at least once)
Which is a damn shame because they are very close to native appearances on both macOS and Windows and are much easier to program than anything Qt. I think it’s the solution I prefer for multi platform GUIs, both as a user and as an occasional programmer.
> Electron or the other variants of 'browser component + JavaScript/CSS and callbacks to a local server
On the other hand, I absolutely hate this as a user. I would lose features and go back to the command line rather than having to deal with this. Everything is wrong in these applications, they don’t support standard keyboard shortcuts, they look weird and out of place and lag where you least expect it.
> TUIs are no solution to the core problem (and it would be absolutely possible to have a GUI toolkit with a TUI renderer for perhaps 80% of GUI needs)
There are a couple of TUI framework that are almost there already. I like the fact that they are useable without fuss over ssh and stuff but I think they are solving the wrong problem. I would rather use something like tmux but that sucks less for the windowing and persistence bits and get more focused and composable CLI. Make a simple REPL with readline so it has a standard and expected behaviour instead of trying to make everything look or behave like an IDE.
OTOH, I really like how this is driving improvement in terminal emulators.
I also agree, wxWidgets is quite great, although I have to also agree with the comment above, that C++ for a GUI library is just a PITA when used from any other language. AFAIK the consumers from wxWidget (wxPython, wxErlang?, ...) are using a C wrapper around the C++ wrapper to use it.
I feel seen.
I also think there’s a certain element of reacting against absolutely everything becoming a bloated electron app.
I have no doubt - if it hasn’t already happened - that some apps will unironically embrace the most ridiculous option by shipping as electron apps that implement a TUI layer as their front-end.
Claude code is almost there
https://levelup.gitconnected.com/theres-a-react-app-running-...
A significant number of these apps are nodejs apps so it’s not that much of a leap!
We need to advocate and evangelize for native apps, like RapidApi on macOS and also Tower.
Jokes aside, I don't understand how devs can bring themselves to ship such inefficient apps.
Companies make UI/UX to prioritise first 30 minutes of the experience, to keep user using it long enough that they stick with it. Not the 8h/day work the UI will get when a tool become pillar of your work.
since time immemorial?
I assume you mean "orders of magnitude" and not "out of memory". I have never seen the former used as an acronym before, let alone without some kind of contextual clue. (In typical Baader-Meinhof fashion, I'm sure I'll see it again in the next 24 hours...)
I, of course, pretend I'm Zero Cool.
Everyone will have a “reasonable” explanation though for why they have to stay in the terminal even when they aren’t really coding anymore and it wouldn’t be hard to have a window next to your terminal if you really have to, but live and let live. Whatever makes you happy as be all become managers.
I too like a cyberpunk interface even if it’s last the need :)
Obviously both are capable of the other.
The vanilla HTML styles look bare, so you have do _something_. TUI’s look sort of cool in their simplest form.
Are people really that put off by seeing some text on a screen and nothing more? Is tmux that difficult to learn?
I can see some point to having an auto-updating dashboard or the like, though.
TUIs just solve the right problems in the same world we're already working in - the terminal. That they're fast to launch and terminals have modern features like rich color and mouse support just adds to that.
I'll stick with Emacs as my TUI platform of choice, especially for tool-assisted development.
This makes it much easier to build cross-platform TUIs. It used to be a chore, now it's probably easier than most GUI frameworks. (Possibly with the exception of Electron, but that comes with a different set of trade-offs.)
You are confusing cmd.exe with conhost.exe
The console is conhost.exe. Conhost (Console Host) is the same kind of program as Windows Terminal, iTerm2, Konsole, Ghostty or Linux Console (the console that Linux uses on text mode)
The shell is cmd.exe (Command Prompt). This is the same kind of program as PowerShell (powershell.exe or the cross platform pwsh.exe), bash, zsh, fish etc. It's also similar to any TUI program such as Far Manager, mc (Midnight Commander), lazygit etc.
The very early DAWs kind of had TUIs, to be fair. Things like the Fairlight CMI
At a former job we had automated extraction of data from a 3270 terminal (several of them actually).
It would in fact work pretty well for a tracker.
And who said text isn't a useful medium? We are discussing how it is displayed which today is on bitmapped displays.
> The issue with GUI systems is that output != input.
Can you elaborate?
You get composition, scaling, accessibility features and a host of other benefits in the box that any other toolkit for GUI adds a lot of developer overhead.
Which is essentially exactly the same thing, except your UI is trash relative to a normal GUI
<Meta> <Super> <Alt> <Control> <Space> <Control> <Alt> <Super> <Compose/Meta> <Greek>
I have left Control mapped to Meta, {,Mu}Henkan mapped to Control, Kana to right Alt, right Alt to Super, Menu to Compose/Meta (tap/hold) and right Control mapped to Greek.
I use keymapper[0] to do low-level remapping and tap/hold, and a custom XKB layout for the Greek modifier. I highly recommend this setup.
The inherent lack of UI bloat is an added bonus.
I mean they mentioned Jetbrains, it could be either.
The problem is that world went away from that and into HTML/CSS/JS/DOM mess that makes simple UI things hard and complex UI things slow and/or hard, on top of the bloat.
VB6 could have you roll a GUI interface in minutes, so even trivial tasks could have a GUI.
The tools for CDE on Unices were arguably even better but CDE never really got any momentum.
That it’s tough to put together a GUI now is definitely a regression and Microsoft shooting themselves in the feet regularly over the last 25 years is squarely to blame.
Likewise, Gnome has proven that you can write entire UIs in Javascript and have them be quite performant.
Electron (well, Node is a big sub-culprit) and Javascript in general just make it really easy to create a slow, bloated application.
Anything after that is time memorial I guess.
(28 year emacs user)
> These days the term native app is so confused it's hard to come up with a definition that doesn't include electron.
Electron is _not_ native.
On Linux that doesn't happen. First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed. Second of all, even if you do ship the source code, you're going to be forced to maintain it. If you made an app in GTK 1 (which looks beautiful, by the way, compared to modern GTK), people won't be able to just install it because GTK 1 is so old that it's no longer in the repositories.
An app made in Java 8 runs in the modern VM. An app made for Windows 95 still runs on modern Windows.
It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
Binary compatibility means closed source has a chance to grow in an ecosystem. It requires "responsible" developers to put more effort into designing APIs and keeping them alive. It adds complexity that requires a more stable set of long-term developers; in contrast, the constant churn in FOSS requires lower barriers for contributions. With stable APIs/ABIs you have to live with decade-long mistakes. You cannot "just fix it" in a next major bump.
You mean openssl? That said, if we can have /dev/tcp, why we can't have /dev/ssl?
That's so very not true.
Most Linux distros allows for custom repositories. So you can just setup the build infrastructure on your side and then have the users include your repos on their side. No need to open source code and users have painless update notifications.
> It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
Lots of users have never seen the source code of their software, they just get the binary package. The pressure you're talking about is imaginary.
WINE is often somewhat jokingly called a more stable platform for Windows programs than Windows is but there's truth there.
So why would you want Discord to be consistent, when you're mostly using the same desktop (or switch between at most two) for hours.
The thing is when HIG were followed instead of everyone trying to create their "brand", everyone knows where the common actions were. You learned the platform and then can use any app. With the new trend, you would only have one computer, but any new app is a new puzzle to figure out.
Two apps can have different CSS while being easy to understand because the core flows and ideas are the same. While many older native apps feel like junk draw UI with crap thrown everywhere and weird app specific quirks and patterns. Even if it all does use native inputs and windows.
I've rarely seen that turn out very well. Typically it works ok on whatever desktop main developers use, and not so much on the others. That means using multiple frameworks, witht their own idioms and quirks and having to repeat a lot of work. Unless your UI is very simple it is pretty expensive to maintain multiple separate versions of it.
Yes. It’s more work than dumping Electron on users. Quality often is.
I think we'd all be better off if we just declared qt the standard gui library and rid ourselves of the chaos we find ourselves in
I briefly evaluated a bunch (had an LLM make a list of those that satisfied some basic criteria, then visited READMEs and websites) and chose nono. No regrets: https://nono.sh/
Arcane build system. I mean, I guess it technically supports CMake these days, but I have never been able to get anyone else's Qt project to build without much gnashing of teeth.
Emulated native widgets try for pixel-perfect, but tend to feel wrong somehow.
> Gtk
Outside of a Linux/Gtk native environment, Gtk applications are awful. Take GIMP on macOS, for example: it's had window focus issues (export dialog getting lost behind the main application window) literally ever since Gtk on macOS dropped the XQuartz dependence. And that's the flagship application for the toolkit.
I looked at this: https://doc.qt.io/qt-6/cmake-get-started.html ... and I'll admit they seem to be hiding some nasty stuff under the hood. But it still seems workable. I guess the devil is in the details?
Granted, not the best measure of memory usage. But the GTK 2 version was 30mb.
Even if I end up liking virt-free like nono stuff for agents, I am trying to explore and learn about microVM options lately for other development purposes as well. This is a serendipitous recommendation for me. :D
I do a lot of work in the terminal and that's exactly why I'd rather have other windows to the side so that my terminal can stay exactly focused on what I'm doing there. Those other windows might also be terminals, but I have a big screen, and I want to make use of it to see things all at once. A GUI gives far more flexibility for arranging those multiple views.
I've sat with coworkers taking two to twelve keystrokes to flip between things that I just have side by side in separate IDE windows, browser windows, or tabs... or can switch between with a single click instead of those keystrokes.
Multi-monitor terminal juggling also probably loses out to GUIs, though for me it's usually IDE or Browser on one and multiplexer on the other. One big zellij session connected to multiple terminal emulators is probably the best way I could think to handle that.
Depends very much on your window manager. Tiling window managers such as Hyprland let you open multiple windows and it will automatically arrange them side-by-side. Want one of them to be 60% and the other 40%? No problem, there's a keyboard shortcut (configurable) for that. Have four windows open in a grid arrangement and want to switch between them? Just slide the mouse, no clicking needed so the movement can be as rough and imprecise as you want, OR if you don't want to take your hands off the keyboard then SUPER+arrow keys (also configurable) will move the focus to the next window in that direction. (And if you are in focus-follows-mouse mode then it also moves your mouse cursor to be in the middle of the focused window, so you won't lose window focus by accidentally bumping your mouse and moving it one pixel). Keyboard shortcuts for maximizing and un-maximizing windows, for throwing them onto other workspaces and switching between workspaces...
I throw windows around my screen all the time, and rarely take my hands off the keyboard to do it. It's the fastest, most flow-like window manager experience I've found yet.
That said, obviously it depends on the use case. I’m not going to make a tui to interact with locations on a map - a web app makes a lot of sense in that case. But something like lazydocker makes sense more sense as a light terminal based program
