251–260 of 580 posts
Agree with the rest of the comments here: keep making TUIs. Fully keyboard-driven, compact interfaces that live in my terminal with the rest of my CLI devtools are the best!
The only one I use is Copilot (inside of a VM). ALl other applications I use are GUI/CLI/webapps.
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…
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…
It’s extra mentioned that CLIs are mostly a good idea but TUIs aren’t.
Counterpoint: Build more TUIs in Rust using Ratatui: https://ratatui.rs/ Why? Because just look at the examples on that page.
I guess it’s a matter of taste ¯\＿(ツ)＿/¯
> Nothing is stopping you from designing a dense and economical GUI. Then why isn't it done more often? I suspect part of the reason is that most gui frameworks are not really designed for making dense economical interfaces. > you probably don’t need a user interface on prod. You need a command line interface on prod that I don't need one, but I often want one. Being able to run vim, htop, etc. on servers is quite us…
Because it tends to require a lot of thought and effort along totally separate engineering pathways than most of the actual functional coding. Good UI design is not easy, and the skills to do it don't directly overlap with good coding skills. It's hard.
> I suspect part of the reason is that most gui frameworks are not really designed for making dense economical interfaces.
Don't blame the tooling for a broad failing of many developers. It's because constructing a genuinely dense and economical interface for most apps requires considerable time and effort, and frankly, most developers are crap at understanding how users other than themselves use applications. Those that aren't crap at it tend to have worked in large teams with dedicated UX people to help drag them away from their preconceptions.
this blog post is mostly shadowboxing and showing off their llm-made software; kind of disappointing
Earlier quoted context omitted.
> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc. Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?
Countless reasons. Invent a gui client environment that is universal, works the same way everywhere, over any kind of channel, and is already implimented and supported everywhere, and utterly weightless in all dimensions (ram/cpu/network), and then you might be able to ask that question without it being incredibly ignorant. Today the closest you might be able to say is web/electron, which is gross on all counts. If a…
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…
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 architecture that of modern graphics display that's predisposed to that, it all ends up as GPU commands.
I'm sure you could get most of the way to what I'm describing with just replacing the font/character set with one that renders things like borders in greater detail.
Hell, you could even add this as post-processing. You look at the terminal output with cellular automata like rules, and try to render UI primitives fitting that.