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

251–260 of 443 posts

Re: Why TUIs are back

#251

Post by smackeyacky »

xiaoyu2006 wrote: post #150
dbish wrote: post #10

Earlier quoted context omitted.

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…

But GUIs are hard to built - mainly because of tech debts around all three major platforms. But nontheless displaying graphics is harder than outputting control chars.

This is a recent development.

VB6 could have you roll a GUI interface in minutes, so even trivial tasks could have a GUI.

The tools for CDE on Unices were arguably even better but CDE never really got any momentum.

That it’s tough to put together a GUI now is definitely a regression and Microsoft shooting themselves in the feet regularly over the last 25 years is squarely to blame.

Re: Why TUIs are back

#252

Post by skydhash »

thayne wrote: post #67
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.

I don't think it is lack of investment necessarily, so much as not building the right thing. What we need is a framework that is easy to use, cross platform, open source, and ideally can be used from your programming language of choice.

> cross platform

That's one word that should never been used in an design meeting. None of the GUI I've used has managed to do this right. Even Emacs and Firefox. The platform are totally different (and in the case of Linux/Unix, there's a lot of different HIG competing). So trying to be cross platform is a good illustration of the lesson in https://xkcd.com/927/

The best bet should be a core with the domain with a UI shell. And then you swap the shell according to the platform.

Re: Why TUIs are back

#254

Post by Dwedit »

We need lightweight HTML/JavaScript applications that aren't an entire web browser. You already have a web browser installed, you shouldn't need yet another copy of Chromium to run some HTML/JS files. Because browser makers cripple HTML files run from your own computer (can't fetch any files, even from the same directory), you are forced to start a web server just to run HTML and JS files from your own hard drive.

If you have python installed, you can start a web server with a couple lines of shell script. Is there any really good truly lightweight webserver? (Something under 256KB)

Re: Why TUIs are back

#255

Post by [deleted] »

criley2 wrote: post #91
_jackdk_ wrote: post #71

Earlier quoted context omitted.

I don't think that's true, because it appears to me that the upswing in new TUI programs predates Claude Code's takeoff.

Claude Code uses Ink, a react library in javascript for UI. The upswing is probably stuff like this making it super easy to write a TUI.

[deleted]

Re: Why TUIs are back

#256

Post by rmunn »

keyringlight wrote: post #154
james_marks wrote: post #93

Earlier quoted context omitted.

Hot take: TUI’s default to providing utility, GUI’s are prone to extra style/bloat. Obviously both are capable of the other. The vanilla HTML styles look bare, so you have do _something_. TUI’s look sort of cool in their simplest form.

It's an aspect I've wondered about, constraints do make you consider what's essential. For example in btop (screenshot in the article) the graphs are rendered with dots at low resolution, if there was another version where those graphs were full resolution is it telling you meaningfully more?

Since the dots in btop's rendering are using the Braille characters, meaning you get six dots in the space that would be taken up by one alphanumeric character, the resolution on those dots is surprisingly high. A maximized terminal on my screen is size 316x86, so that's 316×2 x 86×3 = 632x258 of "Braille dot resolution" (a term I just made up) available for the graphs. Sure, that's lower than the 2560x1600 pixel resolution of my screen, but you're entirely right to ask "Does that really matter?" The graph would be smoother with about 4x more horizontal pixels and 6x more vertical pixels to work with, but I doubt I would glean any more information at first glance.

Re: Why TUIs are back

#257

Post by Gigachad »

skydhash wrote: post #252
thayne wrote: post #67

Earlier quoted context omitted.

I don't think it is lack of investment necessarily, so much as not building the right thing. What we need is a framework that is easy to use, cross platform, open source, and ideally can be used from your programming language of choice.

> cross platform That's one word that should never been used in an design meeting. None of the GUI I've used has managed to do this right. Even Emacs and Firefox. The platform are totally different (and in the case of Linux/Unix, there's a lot of different HIG competing). So trying to be cross platform is a good illustration of the lesson in https://xkcd.com/927/ The best bet should be a core with the domain with a U…

I want my applications to look consistent across platforms. Why would I want discord for example to look entirely different between MacOS and Linux? With the current state of things, once I use the app anywhere, I'll know where everything is on any platform.

Re: Why TUIs are back

#258

Post by skydhash »

AlienRobot wrote: post #210
einpoklum wrote: post #181

Earlier quoted context omitted.

> 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 so…

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

That's so very not true.

Most Linux distros allows for custom repositories. So you can just setup the build infrastructure on your side and then have the users include your repos on their side. No need to open source code and users have painless update notifications.

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

Lots of users have never seen the source code of their software, they just get the binary package. The pressure you're talking about is imaginary.

Re: Why TUIs are back

#260

Post by Gigachad »

maccard wrote: post #177
dpe82 wrote: post #109

Earlier quoted context omitted.

A year ago I would have agreed with you, but now anyone can build a perfectly reasonable native app.

What is native on Linux?

What is native on Windows too. These days the term native app is so confused it's hard to come up with a definition that doesn't include electron.
Post reply on HN