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

Stop Making TUIs

sockpuppet.org

Post reply on HN
Print view View original

231–240 of 579 posts

Re: Stop Making TUIs

#231

Post by mr_olive »

flossly wrote: post #213
crostlybostly wrote: post #207

Earlier quoted context omitted.

HTML/Javascript would like a word

we need a way to access locally running web apps without doing an ugly http://localhost:8022 and having to remember that. I'd say http://localapps should give an overview of all web apps running locally, with links to them. Those links should follow a naming scheme where the hostname ends with `.local` or smth. So: http://claudecode.local

Hah, I was dealing with this problem today.

My approach: Add entries for my localhost apps to `/etc/hosts`, and set up nginx as a reverse proxy.

Now when I go to `http://myapp.local` in the browser, `/etc/hosts` tells it to go to `localhost:80`. The http server sitting there knows which port to send the request to. I also made a systemd service that starts nginx automatically.

Now I have meaningful URLs for local apps, and I don't have to remember which one is listening on which port.

Re: Stop Making TUIs

#232

Post by Arainach »

Almondsetat wrote: post #229
embedding-shape wrote: post #223

Earlier quoted context omitted.

Maybe not, but they do sit on opposite end of an axis looking something like: TUI that runs on any OS |----------------| TUI without any compatibility mess You really can't have both at the same time, either you have great compatibility (which will be a mess), or you don't, to varying degree of course.

Basically any OS can install any compliant terminal emulator, meaning the cases in which you really have to patch your TUI for another OS are few and infinitely more manageable than GUIs

Compliant with what? The proposal is "throw out all the compatibility and build some other kind of terminal" in which case nothing is portable.

Re: Stop Making TUIs

#233

Post by fp64 »

Surac wrote: post #2

TUI is a kind of self defense. big corps create and kill gui frameworks faster that one can learn them. Browser based ui is a real waste of resources (and also evolve in a absurd pace). The Console is a last resort to write small (understandable) gui that work on many platforms.

I like browser-based UI, as they offer similar advantages to TUIs: You can use the UI on a different machine than the application itself is running. Arguably, modern Web standards also lend themselves to some elegant code design for UI. However, the "waste" is a valid point, but then again your TUI (and many GUIs) will fail on those things that cause the "bloat" of a browser: support for the weirdest encodings, dealing with the most absurd edge cases, supporting the largest amount of devices in a uniform manner. Shipping a whole electron for your crappy app is not what I mean. This should stop, as it trades all advantages for almost only disadvantages.

Re: Stop Making TUIs

#234

Post by lenkite »

0x457 wrote: post #120
Shank wrote: post #27

Earlier quoted context omitted.

Apple believes SwiftUI is the future, not AppKit and UIKit/Cocoa.

Sure, Apple positions SwiftUI as its primary forward-looking UI framework, but AppKit and UIKit still developed and have access to all API that SwiftUI has.

"AppKit and UIKit still developed and have access to all API that SwiftUI has."

No they don't. Many components are SwiftUI only.

Re: Stop Making TUIs

#235

Post by imrebuild »

"But remember: I’m not really building applications for other people to use. I’m building them for me."

You are free to build anything you like, and whatever you build won't affect me at all.

Re: Stop Making TUIs

#236

Post by krzyk »

WhyNotHugo wrote: post #165
sjbzbeiks wrote: post #137

Tabs vs spaces. I’ve always appreciated the positive side of TUIs and appreciated less the positive side of GUIs. I didn’t grow up with a computer at all and in one of my first adult jobs I had to use a TUI at Papa John’s for punching in orders, it was 20x faster than anything I used after it at other restaurants that were GUI driven (keyboard speed wins for me, fit my brain perfectly). I think I learned it in 5 minu…

What you're comparing is really "keyboard-driven" via "mouse-drive". A GUI can be keyboard-driven and as fast as a TUI. The sad truth is that the status quo for GUIs is absolutely terrible, and most were rushed out and not properly tested to check if they're really usable without a mouse.

Yes, but GUIs are by default mouse driven, very rarely one can see a keyboard driven one (I haven't seen any).

And TUIs are only keyboard driven. So the choice for speed if you don't need graphics is always - TUI (or CLI).

Re: Stop Making TUIs

#237

Post by krzyk »

Benefit of TUIs is that sometimes they are extension of CLI.

Sometimes I can use `du` to check what uses so much space, but sometimes ncdu is better for me.

And the best part - I can use both when I ssh to another machine, using the same command line, without thought. While GUIs need added thought, to switch from CLI to GUI on the remote one would need to use a different interface, or have X11 forwarding on (which is also a good option) and x11 libs on the other side.

Or use some other connectivity. ssh is simple, works on most servers I have access to.

Re: Stop Making TUIs

#238

Post by unchar1 »

matheusmoreira wrote: post #224

No, thanks. I don't want a mere "user" interface, I want a programmer's interface . I don't like the command line because I'm a "unix nerd", I like it because it lets me rapidly cook up little programs and execute them. Here's an example I just pulled out of my shell history: c=3afba1a; reset; laptop "virtdev ssh liblinux -- git -C liblinux format-patch -1 ${c} --stdout" | tee /dev/tty | termux-clipboard-set This hug…

From the article

> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.

You're also arguing for CLIs which are absolutely great. But TUIs provide none of the composability of CLIs nor the malleability of GUIs

Re: Stop Making TUIs

#239

Post by dzikimarian »

raincole wrote: post #191
dzikimarian wrote: post #179

Earlier quoted context omitted.

They don't work fine. I run lot's of TUIs because they are snappier. You may bury this problem with money buying 64gb laptop, but that facade falls as soon as you launch local LLM and discover there's no space left for Spotify.

Believe or not, millions of programmers (presumably the most tech-savvy demographic) use VSCode for their daily job.

Because it currently has best support for their stack. Being tech-savvy means also you understand, you can't move entire plugin ecosystem of vsc to notepad++ and call it reasonable.

Re: Stop Making TUIs

#240

Post by MereInterest »

MintPaw wrote: post #121
hombre_fatal wrote: post #21

One of the biggest upsides of TUIs over GUIs is that I can run any number of TUI instances. Meanwhile a GUI's developer has to decide to grace me with the ability to even open more than one window. "A tabbed interface will be sufficient!" -- yay, I'll never be able to view two screens of info at the same time.

Why would this be true? The way "single instance mode" usually works is by taking a global mutex or making a lock file. What makes this not possible for TUI apps? Isn't it just culture?

My guess is that is because a TUI can’t give focus to the existing instance. When a GUI application realizes that an instance is already running, it can ask the windowing manager to unhide and focus the running instance.

For a TUI to do the same, it wouldn’t just need to find and focus the window, but would need to trace it through the myriad ways that a TUI can be displayed. I may run a TUI inside a docker container, as part of a tmux session, over ssh. If a TUI somehow managed to focus the existing instance through those layers of wrapping, I would be very surprised, disgusted, and impressed.

So I think it’s that the end goal of “redirect user to existing instance” is infeasible, so nobody bothers to enforce a single instance, since the rest of the steps aren’t possible.

Post reply on HN