Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

if ai makes native rewrites cheap, "write once run anywhere" matters a lot less. tuis stick around for dev workflows, not for shipping to users.

I do get that, but developers like native UI too. You can tell by how much we gripe about Electron!

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.

Why not instead have Linux just run Win32 applications?

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.

how's that any different than electron, it's also sticking out with all of its widgets being different than native

Materially, it's not. Which is what I'm arguing.

- 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.

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.

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...

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.

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.

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.

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.

> 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.)

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.

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.

Reply on news.ycombinator.com