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

331–340 of 580 posts

Re: Stop Making TUIs

#331

Post by iskra »

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

Rather than typing http://localhost:8022, name each app and put them behind one local proxy:

1. In /etc/hosts (or dnsmasq): 127.0.0.1 ourapp.test 2. Caddy in front: ourapp.test { reverse_proxy localhost:8022 }

Caddy auto-provisions local certs, so you get https://ourapp.test, no ugly ports and no "not secure" prompt.

For the overview idea: a tiny local dashboard that scans common dev ports (3000, 5173, 8080...) and lists each running app by name is a ~100-line utility. This is exactly the kind of small tool I build, happy to make a quick version for you.

Re: Stop Making TUIs

#332

Post by RunSet »

never_inline wrote: post #296

> I’m not packaging this application up. If you want it, just screenshot this section of the post and give it to Claude. It’ll build something useful. You see where I’m going with this. This pretense that the entire value of source code is the "spec" / "requirement" is alarming. The value of the code is how well-formed the spec is + how well tested it is in the real world. So prompt / mockup cannot replace code.

I did see where they were going and that was when I closed the tab.

Re: Stop Making TUIs

#333

Post by the__alchemist »

Three broad notes:

- I'm team GUI! The author outline elegantly why. Sometimes I put command-line-like things in the GUI; I generally view it as a superset of CLI, with vastly richer capabilities. This is kind of interesting in the bioinformatics/structural bio space, which I feel is inherently visual, and benefits from 2d layouts. Most of the tools are CLI and based in I/O of stdout and text-based files. I am taking a different direction!

> 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. The Eloi use GUIs like Microsoft Word. Because this is high-test fan-service, “In The Beginning Was The Command Line” has become one of our field’s sacred texts, despite very little of it holding up 25 years later.

We should not take Sci-Fi and creative plot devices as predictions for the future. They can be inspirations and motivations for your own creativity, if tempered by realistic expectations and discipline. Neal Stephenson is especially prescient (Certain concepts from Fall; or Dodge in Hell and Anathem are hitting home strongly right now!). He spins vibrant, speculative yarns, mixing concepts, and estimating trajectories. The story referenced he is one that's in particular easy to see what parts did and didn't pan out. (And what Neal's more recent reflections on it say)

I think there is a bit of cultural identity (Which we are genetically inclined to insert in all sorts of places!) going on. There is a certain cyberpunk fun in SSHing a terminal, pipeling stdout/in together, and Viming. I suspect there is a high overlap between people for whom Linux is part of their identity, TUI use is as well. I.e, it's not about a practical weighing of merits; standard identity/tribal-based choices.

FOr use of TUI as a general file browser/command-executor... I've made my own. It's a GUI, and has built-in terminal for executing commands, with a visual file browser. And most importantly: Shortcuts to execute commonly-used workflows, history, bookmarks etc. All of which I feel like are glaring things missing from standard terminals. (PS, Bash etc). And having a terminal as one part of a multi-window program feels like a good use of my screen space!

Re: Stop Making TUIs

#334

Post by jrop »

joshka wrote: 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…

The approach you're describing (redesign the protocol) is one path. Another is to sidestep the protocol entirely by using a platform that already owns its rendering surface and happens to run in a terminal: my preference is Neovim.

Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, you're just buying another learning curve. Also, the language is Lua (not Rust) so it won't appeal to the ratatui crowd on that front, and there's no proper layout system yet.

Neovim [0] renders to its own buffer system (extmarks, floating windows, virtual text) rather than emitting ANSI escape codes. Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box.

On the UI framework side, morph.nvim [1] provides a React-like component model (h(), state, reconciliation) on top of Neovim. It's not a general answer the way ratatui is, but for the slice of devs already in Neovim (there are dozens of us!), it's a pragmatic way to get GUI-framework-like ergonomics without the terminal protocol fight.

For a sample of what TUIs in this paradigm can look like, I've been working on tuis.nvim [2] (Docker, K8s, SystemD services, process management, and more all as native Neovim buffer TUIs).

[0] https://neovim.io

[1] https://github.com/jrop/morph.nvim

[2] https://github.com/jrop/tuis.nvim

Re: Stop Making TUIs

#336

Post by the__alchemist »

jeroenhd wrote: post #175
anon7000 wrote: post #147

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?

TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. If you're only targeting macOS/Windows/Gnome/KDE then the solution is easy: just grab a GUI control set and go ham. Then there's remote access: you can spawn an X11 app through X forwarding and have a terrible laggy…

> TUIs run on any OS with minor patches to support quirks, GUI frameworks need a lot of work. TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform.

Have you tried to write a GUI program lately? I suspect things may have changed. I can write one using Qt, EGUI, etc (Or many other options), and it will just work on Windows, Mac, Linux/Wayland, and Linux/X.

Basically, you write your application on top of a GUI framework that smooths over OS differences for you.

Re: Stop Making TUIs

#337

Post by rafram »

JodieBenitez wrote: post #285

> Stop Making TUIs No, I don't think I will :) It's great for admin tools, alongside CLIs. It's portable, it's fast, it's discoverable, it has zero bullshit effects, it's as secure as my shell, it's efficient. And what is this point about agents making it easy to generate GUIs ? They are equally good (if not better) at generating TUIs using any of the great frameworks for this.

> It's portable

Not really?

> it's fast

It's not - most terminals are ridiculously slow, and each TUI framework requires its own hacks to do partial "repaints" using ANSI escapes, because clearing and redrawing the entire screen (yes, just a screen of monospace text!) is unworkable.

> it's discoverable

With no ergonomic way to build a menu bar, display hints/tooltips, or even support modified keyboard shortcuts well across platforms? I don’t think it is.

> it's as secure as my shell

Extraordinarily insecure, in other words.

> it's efficient

As above.

Re: Stop Making TUIs

#338

Post by breppp »

TUI and Rust surged back in popularity when programmers through frameworks became detached from the actual work and needing to differentiate from all others in the even playing field. It's like turntables to Hipsters. Now with LLMs it is only going to get worse.

Re: Stop Making TUIs

#340

Post by xgulfie »

tomaskafka wrote: post #309
jbellis wrote: post #281

Unfortunately we seem to live in an era where your mainstream choices for a cross platform app are "Electron taking 1GB when idle" and TUI.

No, that is 2 years ago era. Now it’s “native apps for 5 platforms done almost for free” era for anyone who cares. See Meta’s new AI desktop app (no, I won’t install anything from Zuck on my computer, but I appreciate what they did).

> Now it’s “native apps for 5 platforms done almost for free” era for anyone who cares.

Can you elaborate?

Post reply on HN