Live data from Hacker News

Stop Making TUIs

sockpuppet.org

451–460 of 580 posts

Re: Stop Making TUIs

#451
post #252

Earlier quoted context omitted.

I agree, authors whole "The time has come to re-evaluate terminal and command line interfaces." is weird, if anything we should be moving MORE towards terminal and command line usage. Another example from recent history, I just wanted a easy way to mount all connected drives, so whipped up: lsblk -l | grep -i part | cut -d " " -f 1 | xargs -I{} sudo mount -m /dev/{} /mnt/{} # automount_all How would you even approach…

The article is not against CLIs but TUIs. It’s extra mentioned that CLIs are mostly a good idea but TUIs aren’t.

> The article is not against CLIs but TUIs.

Isn't it against both? Maybe I'm reading it wrong then, because things like these certainly seem against CLIs:

> Back in 1999, Neal Stephenson wrote an essay about command line interfaces that set the field of human-computer interaction back about 20 years. In it, he depicts the priesthood of Unix nerds wielding CLIs as powerful Morlocks, holding the entire computing industry on their shoulders.

> If you haven’t tried your hand at turning one of your 500 throwaway CLIs into a native app, you’re doing yourself a disservice.

Maybe I'm missed something else, but I certainly got the impression the author isn't very impressed by CLIs.

Re: Stop Making TUIs

#452
post #118

As a ratatui library maintainer, NO - please don't stop making TUIs ;) As a developer outside of that, I love the scratch the itch apps stuff mentioned in here. I have a vibe coded SwiftUI chess repertoire builder app that fits in that same sort of space that I'm currently working on, where I'd probably not have chosen to explore the idea if not for coding agents. I agree with the article that the terminal is an odd…

I’ve found some of my favorite TUI apps by scrolling around in the built-with-ratatui page. I have always bounced off of rust but ratatui must be a great library!!

Re: Stop Making TUIs

#453
Accessibility is a giant problem with almost every open source GUI library too.

It seems like an absolute slam dunk for AI. Create an integrated AI screen reader app that observes the screen and talks to you. It wouldn't even need to be a huge model. It could be a small local model that can just read and interpret UI elements and feed the results as tool use calls into an accessibility layer. It'd probably be a custom trained accessibility model, could probably be based on an existing small computer use model fine tuned for the purpose.

This seems like the "accessibility solution to end all accessibility solutions" that totally takes the burden out of the code and puts it in one place that can be uniformly improved.

This is the way. It just wasn't possible 5 years ago.

Re: Stop Making TUIs

#454

Hard disagree. Make more TUIs! TUIs have downsides like accessibility, poor mouse support, but work really well if you focus on keyboard input. It is a better/faster input mode to begin with, especially for power users, but also for average people; you'd be surprised at how much more user-friendly an arrow-keys driven UI can be vs modern web interfaces. I've been building my own TUI framework [1] and getting amazing…

Yeahs ago I remember when my big bank switched from a TUI front end to a web front end for their front line staff. What originally took a few quick keyboard/tab combinations that was hard wired into employee muscle memory immediately took 2-3 times longer. Fortunately, the need to go into a physical bank doesn’t matter as much, but it’s still a regression…

The truth is that the web is a shit GUI framework. It's slow, clunky, incredibly resource intensive, hard to make uniform, verbose to code. It's terrible.

The way the whole industry adopted it is understandable given the install base, but it's also probably a trillion dollar tax. I'd hate to see how much additional energy is used by billions of end-user devices running a rendering layer that is 100X heavier and more CPU intensive than anything native or TUI.

Re: Stop Making TUIs

#455
post #208

Earlier quoted context omitted.

>So because TUIs look universally bad You can't stay engaged if the menus don't bleep and bloop at you and confetti rains down on every click? That's a personal problem. A minimal UI is not automatically a bad-looking UI.

No, but I want to click to place the cursor in my 10 line prompt wherever I want. I want to double click to mark words. I want to use a scroll bar. I want to copy paste properly and not "23 lines pasted". I don’t want to read docs to find all keystrokes the TUI supports to achieve what I want.

>I want to click to place the cursor in my 10 line prompt wherever I want. I want to double click to mark words. I want to use a scroll bar. I want to copy paste properly and not "23 lines pasted"

sounds like your terminal emulator is just crap, terminal and iterm on mac just work

Re: Stop Making TUIs

#456
post #248
post #236

Earlier quoted context omitted.

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

Emacs is primarily keyboard driven.

Is there a GUI Emacs? I used only TUI one.

Re: Stop Making TUIs

#457

The typical TUI fan is a nerd with no clue about typography so therefore they don't notice any problem with being shown elements that have no reason to be monospaced in monospace. i.e. ignorance is bliss in the world of typography.

Perhaps the average TUI fan is someone who correctly recognizes the negligible relevance of typography in optimizing their computing workflows, and prefers monospace fonts for purely functional reasons, which naturally take precedence over merely aesthetic concerns when working with functional tools.

The total abandonment of the form-follows-function principle on the part of purely visual designers, who worry about what software looks like without considering what it's for, has led to 10-15 years of cumulative usability degradation in almost all categories of software. TUI and CLI software remains one of the last bastions of people actually designing interfaces for functionality and usability.

Re: Stop Making TUIs

#458
post #286

Earlier quoted context omitted.

I have a question - I've briefly looked at the API, and it seems like a mostly general-purpose user interfance library. What do you think of replacing the 'render' part with something that's more like a generic UI? You could keep the UX the same, yet your app would look like a desktop app (or at least close to it). Trying to fit in the limitations of 80x25 text rendering is cool, but there's nothing in the underlying…

If you're redesigning a protocol layer, then I'd say you still want to target fixed size cells as the unit of rendering. It's just not the central abstraction like it is in the current terminal approach. Because you're one step above here, you have th ability to do better border handling. There's a lot a things you miss trying to force borders through a character set thing (e.g. missing characters depending on your f…

I was suggesting something that could be done without changing the protocol itself.

From what I undestand, the terminal is essentially a concatenative text buffer extended with control commands allowing you to move the cursor (pen) to draw more sophisticated stuff, and update UIs.

The logical way to extend this would be to allow genericdrawing commands over the protocol, at which point the whole thing starts sounding like X11.

I'm sure the Unix people at MIT in the 80s saw this as the natural evolution from text terminals to graphics based ones.

Not saying this is a bad idea, but sounds suspiciously like a retread of history.

Or you might want to stop before that, as you suggested, at targeting fixed size cells for rendering, and keeping the console-like UX throughout. I'm sure there's a sensible intermediate step, but if you want to do things like displaying graphs or images (turning the terminal into something that's halfway between a terminal emulator and a Jupyter notebook), it'd be awkward to respect the character grid and the non-square characters themselves.

I'm curious what you think about how far this new protocol should go, and in what direction. You mention 'semantics', as describing behavior, not just what gets drawn to the screen, which neither X11 nor tty does.

Re: Stop Making TUIs

#459

Earlier quoted context omitted.

GUI programs can also use the keyboard.

A lot of us do the vast majority of our non-browser work on remote systems. GUIs are objectively bad for this

X Windows was invented on the 1980's and isn't the only way to graphically access remote systems.

Modern cloud systems shouldn't even have shell access, immutable containers with telemetry data.

Re: Stop Making TUIs

#460
post #454

Earlier quoted context omitted.

Yeahs ago I remember when my big bank switched from a TUI front end to a web front end for their front line staff. What originally took a few quick keyboard/tab combinations that was hard wired into employee muscle memory immediately took 2-3 times longer. Fortunately, the need to go into a physical bank doesn’t matter as much, but it’s still a regression…

The truth is that the web is a shit GUI framework. It's slow, clunky, incredibly resource intensive, hard to make uniform, verbose to code. It's terrible. The way the whole industry adopted it is understandable given the install base, but it's also probably a trillion dollar tax. I'd hate to see how much additional energy is used by billions of end-user devices running a rendering layer that is 100X heavier and more…

Not if you just stick to the basic built-in 30-year-old HTML GUI elements (, , , , , for layout, etc., maybe also some modern standards like flexboxes) which are very fast, lightweight, east to code, and uniform. The problem to me is every website tries to do some custom javascript monstrosity with their own graphics to keep up with the latest fad. When just sticking to the basics, I find the web is a great cross-platform GUI framework.
Post reply on HN