| The tide is going to turn on this in the second half of 2026. There have always been nerds who just love TUIs, and still read their email in Mutt. But I think the subtext of this article is right, that TUIs are back because of how much of a pain UI development is. 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. |
| That still doesn't address the root of the problem, which is that TUIs and Electron apps are write-once, run-anywhere, while native GUI dev is insanely fragmented. 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. |
| |
| ▲ | tptacek 9 hours ago | parent | next [-] | | What does it matter how fragmented the platforms are? I feel like this isn't sinking in with people. I was chatting with a friend last night about a SwiftUI app that I'd built and he'd pitched in on. He then reimplemented --- didn't port it, reimplemented it, for WinUI, that night, with just a couple prompts. I am, in a proverbial sense, buying puts on Electron. | | |
| ▲ | dlivingston 3 hours ago | parent | next [-] | | Sure, for small projects. Otherwise, you'd better have a solid plan in place for keeping your business logic in a common core, otherwise you'll just be writing N separate implementations where N = number of target platforms. Even in a world of agents, less code = better code. | | |
| ▲ | tptacek an hour ago | parent [-] | | Sure, I hear this (with current models). But consider the UX complexity of a typical TUI. Even with a TUI framework, you end up with serious coding lifts just to get things that the all the current native UI frameworks give you for free. |
| |
| ▲ | nzoschke 8 hours ago | parent | prev [-] | | I agree, the LLM porting things is a game changer. Does it also follow that we can have pretty much any shape for valuable apps? API, CLI, TUI, Web, SwiftUI, WinUI... | | |
| ▲ | tptacek 8 hours ago | parent | next [-] | | Yes. Developers are conditioned to expect the only convenient answer is a TUI (actually, a CLI; TUIs are show-off projects most of the time) and, if you really want to go all out, Electron. That's not the case anymore. | | |
| ▲ | nzoschke 6 hours ago | parent | next [-] | | I'm with you here. 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. | |
| ▲ | colesantiago 7 hours ago | parent | prev [-] | | [flagged] | | |
| ▲ | akerl_ 5 hours ago | parent | next [-] | | The guidelines are pretty clear that basically all of this comment is not ok, and that this kind of comment is net negative for the quality of the site. > 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. | | |
| ▲ | colesantiago 5 hours ago | parent [-] | | > 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. | | |
| ▲ | akerl_ 5 hours ago | parent [-] | | https://hn.algolia.com/?dateRange=pastWeek&page=0&prefix=fal... That's a good start. | | |
| ▲ | colesantiago 5 hours ago | parent [-] | | Let's check the first one: 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. | | |
| ▲ | akerl_ 5 hours ago | parent [-] | | I don't know why you're so aggressively attacking the idea of people making projects to show off. 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. |
|
|
|
| |
| ▲ | tptacek 6 hours ago | parent | prev [-] | | Every time I read a comment like this, I flash to the episode of the Office where Michael steals one of Dwight's clients while Dwight is on the phone with him in the car. He pitches the client, and Dwight screams into his phone "ARE YOU SAYING YOU INVENTED PAPER?!" 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". | | |
| ▲ | colesantiago 5 hours ago | parent [-] | | > I'm not saying htop and emacs are show-off projects... > 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. | | |
| ▲ | nzoschke 5 hours ago | parent [-] | | The screenshot in the post demonstrates show-off TUIs. 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. | | |
| ▲ | colesantiago 5 hours ago | parent [-] | | The whole point of a TUI is that it is faster than typing hundreds of commands and options you're likely to forget and made a mistake on. 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. |
|
|
|
|
| |
| ▲ | dragonwriter 6 hours ago | parent | prev [-] | | LLM reimplementations for parallel versions are going to be fun to maintain, eepecially when AI market maturity ends the era of AI firms subsidizing coding tools as part of their marketshare competition efforts. | | |
| ▲ | tptacek 2 hours ago | parent [-] | | If you think it’s all a house of cards, obviously none of my arguments hold. I’m not going to hedge that every time I write anything that intersects with AI though. | | |
| ▲ | dragonwriter an hour ago | parent [-] | | > If you think it’s all a house of cards, obviously none of my arguments hold. 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.) |
|
|
|
| |
| ▲ | Ekaros 10 hours ago | parent | prev [-] | | Why not instead have Linux just run Win32 applications? | | |
| ▲ | dlivingston 10 hours ago | parent [-] | | That's really not a solution. You're not targeting the host OS for that, which instantly kills that approach for everything other than "we need this to run on Linux and don't care how." You're shipping all of WINE with it. You're sticking out like a sore thumb with Win32 widgets next to the rest of your GTK apps. Etc etc etc. | | |
| ▲ | d3Xt3r 12 minutes ago | parent | next [-] | | - You don't have to ship Wine with it, you can just make it a runtime/package dependency. Most distros have Wine in their repos anyways, so there's no need to bundle it. I don't see this conceptually being any different than shipping a Python app for instance. - 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. | |
| ▲ | PunchyHamster 6 hours ago | parent | prev [-] | | how's that any different than electron, it's also sticking out with all of its widgets being different than native | | |
|
|
|
