Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?
If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham.
Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy experience on Linux, you can use RemoteApps on Windows to have a good remote experience (but almost no other platform), you can use VNC to have an awful cross-platform experience, or you can use a TUI and have all the graphs and interactivity you need over a responsive, low-bandwidth connection on any combination of client+server.
So because TUIs look universally bad, they're better than cross-platform GUI?
You can't stay engaged if the menus don't bleep and bloop at you and confetti rains down on every click? That's a personal problem. A minimal UI is not automatically a bad-looking UI.
sounds like your terminal emulator is just crap, terminal and iterm on mac just work
qBittorrent looks great on KDE, and would look great on macOS too if they used native icons (I’ve made a theme for that but was too lazy to install it when I was switching laptops). No idea about Gnome and Windows, but probably alright as well.
So, Qt can get you a long way. But you should of course adapt your app to platform conventions and guidelines.
> TUIs run on any OS with minor patches to support quirks
So, which one is it?
TUI that runs on any OS |----------------| TUI without any compatibility mess
In any case we can surely do better than emulating DEC hardware from 50 years ago.
I really think they are. The reason for terminals’ ubiquity is precisely their age, and their age results in them standardizing and accumulating bizarre behaviors.
Even in the microcomputer era, standardizing behavior to where it’s literally everywhere someone might want it takes time (e.g. the browser compatibility wars). Re-standardizing terminal behavior is both chasing a way wider (in terms of the number of places folks expect terminals to work the exact same way) but shallower in feature complexity target compared to browsers, and would necessarily be replacing a widely adopted existing standard behavior, not providing something largely novel like the graphical web was. That’s a tall order. I am hopeful for and impressed by the efforts of folks like Hashimoto, but expectations here should be tempered.
TUIs look bad everywhere, so that's strictly worse
I would definitely be pro minimalist unicode-character-themed GUIs for what it's worth. Where every graphical primitive is basically a unicode character, without the restriction on font size.
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.
Basically, you write your application on top of a GUI framework that smooths over OS differences for you.
This is hard to square with the continuing obsession with Electron.
I thought Claude could do anything nowadays.
Querying into the DOM and working off of that means you're not futzing about holding onto a bunch of component references for the one thing you might need later on.
Web layout is also pretty easy to just get right, native GUI frameworks have a different kind of layout model that is not as amenable to "arbitrary" data (at least at first blush).
the reactive programming model also works quite well. While there are native GUI frameworks that lean into reactive programming, they tend to be doing a bunch of weird stuff that cause other issues.
And at the end of the day, when you package something like a Qt app it still often ends up being quite chunky.
In the end tho... the simplest thing is if you do web stack you get a web UI _and_ your "native" GUI in one go. Build things once, not twice. Hard to argue against that when that's presented.
Mobile has significant paradigm changes that makes using both terminals and traditional GUIs harder anyway though. I do expect the need for completely different cross-platform libraries for mobile UIs.
Also, Qt does support Android development.
The official NDK documentation on what is supported for NDK written code on non rooted devices, and the hurdles that Termux faces to keep running on standard Android images via PlayStore distribution, show why it isn't right.
I expanded on this point nearby: https://news.ycombinator.com/item?id=49400697
I think this is slightly wrong in two ways.
i) If you want platform native then reimplement the gui on every target platform. It’s as ”simple” as that.
If you need to ship to multiple platforms then preferably you need lots of plarform specific engineering in any case.
”I just want my hobby tool” scenario likely does not require cross platform support unless there is market for it. I mean rather than offering the tool on multiple platforms it should be offered on multiple languages first, perhaps. As soon as you are not writing the tool for yourself we are talking markets and distribution. Likely most people can chill out and just implement the gui for themselves (and not even publish it in githubb).
ii) cross platform quick-and-dirty way. Without screenreader support, multiple language and glyph support etc. Game ui:s look the same on all platforms. Websites look the same on all platforms.
There is place and time for deep ui engineering that respects the _critical_ cross platform issues like accessibility (screen readers etc) and different languages and scripts.
And then there is the situation where you want just few images to click. The latter is vastly simpler, fast and fun. But harder to convert to a professional quality gui experience. For small tools and MVPs this sounds like a fair tradeoff.
good dx, cross platform, fast, not ugly.
pick i dunno 2 or 3.
tui's get to check 2 or 3 of these just like any other gui library. somehow there still isn't a silver bullet here.
now i personally don't build tuis but guake style dropdown simple command and i have some other thing someone made open immediately running in ghostty? hell yea. with that said yes there are some stupid tuis out there that are anything but simple.
You can make slow things with it of course but it's not inherent.
The closest in spirit is Probably something like Dear ImGui[0] and the ecosystem of components and apps built with it, but it's not quite there for me. Something is missing.
Invent a gui client environment that is universal, works the same way everywhere, over any kind of channel, and is already implimented and supported everywhere, and utterly weightless in all dimensions (ram/cpu/network), and then you might be able to ask that question without it being incredibly ignorant.
Today the closest you might be able to say is web/electron, which is gross on all counts. If anything the closest is X11, which is not remotely close enough.
That's why not just...
I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth.
My approach: Add entries for my localhost apps to `/etc/hosts`, and set up nginx as a reverse proxy.
Now when I go to `http://myapp.local` in the browser, `/etc/hosts` tells it to go to `localhost:80`. The http server sitting there knows which port to send the request to. I also made a systemd service that starts nginx automatically.
Now I have meaningful URLs for local apps, and I don't have to remember which one is listening on which port.
Malware will thank you.
1. In /etc/hosts (or dnsmasq): 127.0.0.1 ourapp.test 2. Caddy in front: ourapp.test { reverse_proxy localhost:8022 }
Caddy auto-provisions local certs, so you get https://ourapp.test, no ugly ports and no "not secure" prompt.
For the overview idea: a tiny local dashboard that scans common dev ports (3000, 5173, 8080...) and lists each running app by name is a ~100-line utility. This is exactly the kind of small tool I build, happy to make a quick version for you.
That same Pi won't even blink at a local TUI.
No just ignorant most likely. I can see how a child might think that an http/html session qualifies as providing all the same utility of a tty. Well it does not remotely by orders of magnitude.
I already said in the comment to begin with: "The closest you could say is web/electron, which is gross on all counts."