Live data from Hacker News

Why TUIs are back

wiki.alcidesfonseca.com

201–210 of 443 posts

Re: Why TUIs are back

#201
I think it's the smoldering ruins of the OS vendor self interest collapsing in on itself.

There's not a single good universal UI. The best is the browser and it is reasonably successful but the sandbox makes it specifically unsuitable / high friction for doing things that need local access to files, network, etc. And it is ridiculously high overhead if you just want to run something simple. Then remote access is even more a debacle. Can I access an application running on my windows host from my Mac? can I forward that through a tunneled connection?

TUI is a simple, universal protocol that does what you need and is natively remote. Whatever I use locally will seamlessly work over an SSH connection.

And it's a big middle finger to the OS vendors who thought locking everyone in by making everything incompatible or ecosystem specific was a winning strategy.

Re: Why TUIs are back

#202

I think part of it is also that we're able to still LARP as full developers of complex systems while vibe coding by seeing an interface that makes us look like l33t h4xx0rs even though we're just pressing continue 15 times

I associate CLI prompt and typing 100wpm and lots of scrolling logs with l33t, but claude code is more 1992 DOS program vibes.

Re: Why TUIs are back

#203
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…

Claude code amplified the trend hundred fold but there was already a significant increase of TUI since the days of go fzf, rust ratatui and python rich. My bet would be a desire to do away with heavy browser based UI and the curiosity of trying to test the limits of terminal based rendering.

TUI is popular because a) there are no native GUI frameworks for simple tools that are easy, fast, and simple to develop in at the same time, and b) low fidelity lets you pretend being a UI/UX developer without really being one. The rest is abysmal. It's not automatable at all (the article is wrong on that point), less readable (monospace/no images), very limited (try making a DAW in it...), relies on a ton of ancient cruft in Unix-related terminals, it's not really portable etc etc.

Re: Why TUIs are back

#204

I think part of it is also that we're able to still LARP as full developers of complex systems while vibe coding by seeing an interface that makes us look like l33t h4xx0rs even though we're just pressing continue 15 times

"Claude, write a set of scripts using bash and python that trade this $10,000 on S&P 500 listed stocks until it reaches 5 million, make no mistakes"

Re: Why TUIs are back

#205
post #28

Only for software engineers who are already familiar with terminals. Most non tech people I know and in my company absolutely hate TUI. Even a fraction of software developers who spend most their time outside terminals (especially those that are on Windows and/or use specialized tools/IDEs) prefer to avoid TUIs as well.

Many "non-technical" folks who have interacted with virtual 3270 terminals for all sorts of mission critical tasks would disagree sharply with that assessment. And those are essentially TUIs.

Re: Why TUIs are back

#206
post #201

I think it's the smoldering ruins of the OS vendor self interest collapsing in on itself. There's not a single good universal UI. The best is the browser and it is reasonably successful but the sandbox makes it specifically unsuitable / high friction for doing things that need local access to files, network, etc. And it is ridiculously high overhead if you just want to run something simple. Then remote access is even…

The failure of the modern absurd GUI environment (Windows 11 is a GREAT example) is why I keep coming back to something like a minimalist xfce4 desktop environment. There really isn't a need for all the absurdity.

Re: Why TUIs are back

#207
post #126

Earlier quoted context omitted.

I would try switching to Auto Mode which is their own recommendation as a safer alternative to that but still avoids needing to confirm actions endlessly: https://www.anthropic.com/engineering/claude-code-auto-mode

I’d love to. It’s not available to Claude Pro nor Claude Max subscribers. Eventually I got fed up with waiting and just turned off permissions.

I'm on the $100/m plan and it works.

Re: Why TUIs are back

#208
post #189
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…

The TUI version of ClaudeCode is not even that good compared even to the VSCode plugin.

How come?

Re: Why TUIs are back

#209
post #10

I think part of it is also that we're able to still LARP as full developers of complex systems while vibe coding by seeing an interface that makes us look like l33t h4xx0rs even though we're just pressing continue 15 times

I’m relatively certain it’s just this at the end of the day. Everything I see people doing in their custom built TUIs or claude/codex CLI can be done, likely even easier, in a simplified IDE or easier to scan UI, but it feels nice/cool/cyberpunk/work-like to look like you’re doing more. Everyone will have a “reasonable” explanation though for why they have to stay in the terminal even when they aren’t really coding a…

[dead]

Re: Why TUIs are back

#210

Earlier quoted context omitted.

To me the worst case is trying to develop some small utility like a tool to search in files using regex. Because if you are developing something large, the amount of time you spend dealing with packaging, distribution, etc., is small and you don't care about file sizes. But if I want to, say, develop the app for Windows. That is easy. You get a tiny binary to just opens a form and runs with a double click. No install…

> There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained So don't be self-contained. I mean, you depend on an X server or Wayland, right? So why not depend on GTK or Qt being available? (Of course, it _is_ tricky to be able to depend on any of several versions of these, but still.)

What I mean is that on Windows you can just ship an 100kb .exe and forget about it and it's still going to work 20 years later.

On Linux that doesn't happen. First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed. Second of all, even if you do ship the source code, you're going to be forced to maintain it. If you made an app in GTK 1 (which looks beautiful, by the way, compared to modern GTK), people won't be able to just install it because GTK 1 is so old that it's no longer in the repositories.

An app made in Java 8 runs in the modern VM. An app made for Windows 95 still runs on modern Windows.

It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.

Post reply on HN