Live data from Hacker News

Stop Making TUIs

sockpuppet.org

271–280 of 579 posts

Re: Stop Making TUIs

#272

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…

That example doesn't use any TUI.

The line editing in my shell is absolutely an example of a TUI. It's a simple text editor embedded in the command line.

Re: Stop Making TUIs

#273
post #236

Earlier quoted context omitted.

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

> very rarely one can see a keyboard driven one

Not so. GUIs absolutely should be keyboard-drivable, if they're written to the human interface specs of whichever platform they're hosted on. That doesn't mean they don't support being mouse-driven or even that mouse isn't the default, but in my experience if the developer has taken any sort of care with the interface then keyboard interaction will be at least as good, if not better, with the keyboard.

> And TUIs are only keyboard driven.

Not true either. There's a line in my .vimrc saying "set mouse-=a" specifically because I want to turn off the mouse in that particular TUI app. If a TUI app doesn't support the mouse they've just not added that support, it's not that it's not possible.

Re: Stop Making TUIs

#274

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…

TUIs are not CLI programs though. They're GUIs which render in a terminal

The shell's line editor is a TUI. It's a simple text editor embedded right there in the command line. It can even render your shell history by pressing the arrow keys.

Re: Stop Making TUIs

#275

No. I like them.

What do you like about them? I disagree, but so many people seem to like them that I assume I'm missing something. The main one I've heard before is that they work nicely over SSH, but I assume there must be more?

I use the terminal for most things which are not web browsing hence for me it makes sense to prefer TUIs for "lightweight" GUI needs.

I love how I have to configure font size and family only once in the terminal emulator and not for each program/GUI toolkit again.

Of course, there is no way to replace graphical-heavy programs (GIMP, QGIS etc.) with TUIs.

https://masysma.net/37/why_terminal.xhtml>

Re: Stop Making TUIs

#277

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.

TUI developers could implement the same kind of anti-features. This isn't a trait of GUI vs TUI.

But they generally don't because it us often expected to be able to have multiple open at the same time, e. G., with lazygit.

Re: Stop Making TUIs

#278

Earlier quoted context omitted.

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.

How so? The idea is you build all the OS specific stuff into the terminal, not into the programs running INSIDE the terminal. Think Infocom Z-Machine, at the ultimate level, although obviously emulating a full on virtual CPU is overkill.

In any case we can surely do better than emulating DEC hardware from 50 years ago.

Re: Stop Making TUIs

#279
post #214

Earlier quoted context omitted.

there's a million gui frameworks under the sun and i still haven't found one that feels like what everyone has been asking for: good dx, cross platform, fast, not ugly. pick i dunno 2 or 3. tui's get to check 2 or 3 of these just like any other gui library. somehow there still isn't a silver bullet here. now i personally don't build tuis but guake style dropdown simple command and i have some other thing someone made…

Except web. Which inexplicably got all of these when no one was looking

Not fast.

Re: Stop Making TUIs

#280

Earlier quoted context omitted.

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

It's a fine point if made in isolation, but TUIs tend to be more technical and useful simply because they require using a terminal at all. GUIs tend to be made for the non-technical iPhone audience. So while I'm not fundamentally opposed to graphics, I'm absolutely opposed to the "average user" culture surrounding it. I don't care about the "normal person", I don't want "user experiences" that hide the computer, I wa…

> GUIs tend to be made for the non-technical iPhone audience.

Except for, you know, every serious professional application ever.

Post reply on HN