Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why TUIs are back

wiki.alcidesfonseca.com

Post reply on HN
Print view View original

191–200 of 443 posts

Re: Why TUIs are back

#191

Post by landr0id »

tootie wrote: post #59
giancarlostoro wrote: post #32

Because nobody is investing in native UI development. Electron is proof that if there were a simple to use GUI stack that companies would adopt it.

Zed did. I know it has it's fans, but it doesn't seem to be generating a stampede of adoption despite what looks like a monumental effort to build a GUI system from the ground up.

Their GUI system (GPUI) is not very mature for use outside of Zed. GPUI is basically a UI framework in the truest sense: a framework for building UI... frameworks/components. It has core functionality for async execution, an ECS for grabbing shared resources, and a div.

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.

Re: Why TUIs are back

#192

Post by Ferret7446 »

mgaunard wrote: post #118

Power users have always preferred the command-line, since expressing what you want to do as a programming language is of course much more powerful and productive than clicking menus. 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…

TUIs are much closer to GUIs than CLIs. As a CLI enjoyer, I was resigned to the small win that at least many people distinguish TUI and CLI now but then I saw your comment.

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

Re: Why TUIs are back

#193

Post by zozbot234 »

spankalee wrote: post #121

I really don't get terminal UIs that try to rebuild GUI-like functionality. Don't we think that computer interfaces should get better? We're not limited to a grid of characters to pretend to draw lines and shapes with anymore. You can't even display an image in a terminal without a non-standard terminal like Kitty or iTerm. It's just a shame that we don't have a great cross-platform, streamed, UI system. The web is g…

> It's just a shame that we don't have a great cross-platform, streamed, UI system.

It's called the web/Jupyter. And no, web-driven UI doesn't have to be heavyweight either, any more than HN is.

Re: Why TUIs are back

#194

Post by xmodem »

TUIs suck and the only reason they are seeing a re-surgency of relevance is because everything else sucks more along one or more critical metrics. Given the truly incomprehensible amount of CPU and GPU power we have available, this is truly a blight on our industry.

Re: Why TUIs are back

#195

Post by zozbot234 »

_jackdk_ wrote: post #89

The diagnosis for GNU/Linux is better than I expected but I think is still incomplete. Yes, you have two major toolkits (GTK+ and Qt) and many minor ones (most of which wrap one of the majors). Qt is proprietary but also available under a free software licence, but what if you don't want that that complexity? It feels like modern GTK+ is less of a cross-platform toolkit and more of a runtime layer for libaidwaita and…

The xfce folks are keeping GTK+ 3.x around, mostly for its advanced theming support. Isn't that quite enough?

Re: Why TUIs are back

#196

Post by nzoschke »

tptacek wrote: post #94
dlivingston wrote: post #39

Earlier quoted context omitted.

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…

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

Re: Why TUIs are back

#197

Post by ninth_ant »

0xbadcafebee wrote: post #157

It's nuts that software developers are allowed to design user interfaces at all. They're incapable of making a user interface that isn't text. It's like if plumbers designed houses, they'd make all the floors slope downward, because that's the easiest way for pipes to run. 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 mak…

Allowed? Many if not most of these open source TUI projects were started by individuals or small teams who wanted to solve a problem for themselves.

It’s allowed. You don’t have to use them.

Re: Why TUIs are back

#198

Post by _jackdk_ »

zozbot234 wrote: post #195
_jackdk_ wrote: post #89

The diagnosis for GNU/Linux is better than I expected but I think is still incomplete. Yes, you have two major toolkits (GTK+ and Qt) and many minor ones (most of which wrap one of the majors). Qt is proprietary but also available under a free software licence, but what if you don't want that that complexity? It feels like modern GTK+ is less of a cross-platform toolkit and more of a runtime layer for libaidwaita and…

The xfce folks are keeping GTK+ 3.x around, mostly for its advanced theming support. Isn't that quite enough?

I didn't realise. That's good news. Whether it's enough, I don't know the UI space well enough to say.

Re: Why TUIs are back

#199

Post by [deleted] »

qudat wrote: post #62

I think if you look purely at the numbers, the real reason TUIs are popular is claude code, everything else is background noise compared to it. 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 invol…

[deleted]

Re: Why TUIs are back

#200

Post by tptacek »

nzoschke wrote: post #196
tptacek wrote: post #94

Earlier quoted context omitted.

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.
Post reply on HN