Posted by rickcarlino 6 days ago
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.
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.
> Be kind. Don't be snarky.
> Edit out swipes.
> When disagreeing, please reply to the argument instead of calling names.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
It seems pretty clear that saying most TUI projects are show-off projects does not mean all TUI projects are show-off projects.
Which ones are show off projects? Examples?
Be objective.
That's a good start.
Systemd-manager-TUI: A TUI application for managing systemd services
Somebody said that they use this, so it is not a 'show off' project.
You realise you made a silly sweeping generalisation right? People actually use them.
The claim isn't that zero people use them, or that all TUI projects are made to show off. But most of the TUIs you see land on HN are things somebody made to play around with a technology / scratch a momentary itch.
No shade on those people; making a project that brings the author joy is an awesome reason to make something, and sharing it with folks here is one of the better things about this site. But the TUIs you see here are, by and large, not aiming for (and not going to get) broad adoption.
This is the main problem.
If you're using HN as a benchmark that most TUIs are show off projects, I don't know what to tell you other than you're in a bubble.
No, friend-o, I'm not saying htop and emacs are show-off projects --- though everyone I know who uses Emacs (myself included) uses graphical emacs.
My point is that most developer tooling is CLI, not TUI; most developer tools are shop jigs, not packaged tools. Though most of the packaged tools: also CLIs!
All of them can very quickly be made into native UIs, though.
You'll get further on HN not calling people "very dishonest".
> TUIs are show-off projects most of the time.
Your statement and anecdotes means nothing and are meaningless since you provided 0 examples of the preported "show off" TUI projects.
Maybe you should re-read what you said again before backpedalling after I gave solid counter examples and you provided none.
That git TUI doesn't offer anything over `git` CLI.
The network / battery / performance TUI is redundant with the tools in the window menu bar.
I love the aesthetic of TUIs but their actual day-to-day install base and usage must pale in comparison to CLIs and GUIs.
That is not 'showing off'.
And you providing anecdotes based on a single blog post doesn't change that.
TUIs are not for everyone sure, but they also save developers a lot of time typing and using a mouse.
I don't even like TUIs and this is obvious.
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.)
Even in a world of agents, less code = better code.
- 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.
JS literally destroyed the software landscape. All the bad practices advertised as best.