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

481–490 of 580 posts

Re: Stop Making TUIs

#481

Post by mihaic »

voidnullvalue wrote: post #401
mihaic wrote: post #393

The people that keep arguing for TUIs for everything seem like religious fundamentalists that can't be convinced with any argument that user interfaces should be about the user, and need to adapt to the task at hand. Every time I use Claude Code, I'm wondering why the hell I'm regressing to the level of a machine. I paste an image that I want fixed, and I don't see the preview of it. I can't cut or edit text somewher…

Claude Code should be heavily sandboxed to be used safely. Are you advocating requiring a gfx stack in the sandbox just to use Claude Code?

I don't get your argument. Can't you separate your input box from your execution engine?

Re: Stop Making TUIs

#482

Post by eviks »

i_am_a_peasant wrote: post #476
eviks wrote: post #242

Earlier quoted context omitted.

> TUIs don't need to follow any OS guidelines, cross-platform GUIs always look bad outside of the "main" platform. TUIs look bad everywhere, so that's strictly worse

TUIs would be great if they didn't have to render all text the same size, for me that's the main win with GUIs, you have total freedom with what you can do with your pixels. I would definitely be pro minimalist unicode-character-themed GUIs for what it's worth. Where every graphical primitive is basically a unicode character, without the restriction on font size.

That's not total pixel freedom, you're still limited to text

Re: Stop Making TUIs

#483

Post by joshka »

tptacek wrote: post #419
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…

Ratatui is such great work. The New Terminal, the complete break from VT100, is I think the most powerful rebuttal to what I'm saying about TUIs. My take is that the Morlocks should pack everything that is great about TUIs (and there are great things about them) and move them upstairs to live alongside the Eloi in GUI-land. Let 1000 Bloomberg terminal interfaces bloom. But there's another even more ambitious take on…

> as you're drawing interfaces with punctuation characters

Yeah, in my hypothetical new protocol, the character cell is still there, but it's not the element that drives the main abstraction. The layer above that being more semantic is where the smarts is. So borders, interactive areas, mouse hit mapping to elements, etc. ends up being built into the protocol rather than being a cell level thing. Cells having proper borders being similar to how they allow for underline, being able to have both images and text, ...

I think it's important to do something about the VT100 +kitchen sink stack and to have that as something that still works with that in areas of the new terminal proto. I've got a slopcoded rust library in the works that's about fully mapping the full list of terminal protocols and related things in one coherent library (VT100, ECMA48, DEC modes, iTerm extensions, Kitty, ...). From there I think making that fairly isomorphic with the terminal emulator layer (I have a RIIR ghostty slopfactor there too that fits).

I think ghostty / superlogical looks at this from the perspective of doing pty things and then transfering that calculated state across the wire while doing fun stuff with windows, panes etc. with replay and that sort of thing. I think this is valuable too.

I suspect that there's possibly a way to do a bit of a hybrid on this - normal pty things with the extra sidecar of more semantic structured, but it'll make things more complex for app builders on that side of things.

(On another comment I saw you mentioned "couldn't help noticing how much of the tedious work of putting a TUI together". I think probably textual in python is probably the best of the low ceremony libraries for making TUIs if you haven't checked that out yet. I think someday there will be a good Rust library that has that level of put together-ness. I have some ideas on this for ratatui and have seen a bunch of things that are directionally right for this, but nothing that gets close yet).

Re: Stop Making TUIs

#484

Post by joshka »

torginus wrote: post #458
joshka wrote: post #286

Earlier quoted context omitted.

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…

The problem succinctly is when the terminal emulator only sees cell values and instructions it can't do anything more with things. Two really good examples are implementing accessibility well, and scrolling / changing things above the terminal pane without rewriting the whole history.

Re: Stop Making TUIs

#485

Post by WA »

dirasieb wrote: post #455
WA wrote: post #208

Earlier quoted context omitted.

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

iTerm2. Doesn’t work out of the box or something, but I’ll take a look at my config.

Re: Stop Making TUIs

#486

Post by joshka »

jrop wrote: post #334
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, y…

I have built a pretty full version of that idea in rust (codex tui2). There's a while tonne of downsides that make it basically impossible to really get to 100% good on this.

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

All that is not true. Take scrolling for example. Each terminal emulator implements this subtly differently (mouse/trackpad/speed etc.), scrolling will never feel native unless you push the control of it into the terminal emulator.

There's more than that, each and every point on this becomes something that you have a gap between native and the terminal emulator that you're building to run in the terminal.

See https://github.com/openai/codex/issues/8344 and https://github.com/openai/codex/pull/9640

Claude code and gemini have both had various versions of the same idea at times. I'm unsure where they ended up.

Re: Stop Making TUIs

#487

Post by joshka »

whartung wrote: post #424

I've mentioned this before, but the rise of the TUI is the simply the systemic failure of remote GUIs. The primary value statement of TUIs is that they work over SSH with remote systems. But now, we're hearing rumbles about the limitations of the "modern" terminals with regards to working well with a "rich" TUI. How a raw tty doesn't really cut it since it, at a minimum, can't detect key presses, only actual characte…

one step deeper - it's a failure of WIMP[1]. Imagine if instead of having a border around the parts of an app that make it an app and instead we applied the unix way but to the gui? What if we had lightweight widgets that had a lifetime of their own and could be nested and combined.

[1]: https://en.wikipedia.org/wiki/WIMP_(computing)

Re: Stop Making TUIs

#489

Post by ezekiel68 »

em3rgent0rdr wrote: post #460
api wrote: post #454

Earlier quoted context omitted.

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-pl…

Sure. Except that nobody ever does just stick to those elements.

Re: Stop Making TUIs

#490

Post by shoopadoop »

hylaride wrote: post #412
ricardobeat wrote: post #386

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…

Modern TUIs aren't like the form-based TUIs of yesteryear, though!

They're wannabe window managers.

Post reply on HN