Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a TUI is easy now

hatchet.run

Post reply on HN
Print view View original

181–190 of 262 posts

Re: Building a TUI is easy now

#181

Post by troupo »

baq wrote: post #161
troupo wrote: post #156

Earlier quoted context omitted.

No, no it makes exactly zero sense to have a "reconciliation engine" or React in a TUI. There's nothing to reconcile. You can just output a stream of characters as fast as they appear.

That’s not a TUI, that’s a CLI. Any stateful UI needs a state management backend and a rendering frontend, React isn’t a bad choice for the former.

React is not, and has never been a "state management backend".

There are about a million other ways of doing state management than retrofitting it into both React and TUI.

Parent comment talks about using React for reconsilliation which is React-speak for "we take a diff between current state of UI and new state of UI, and apply that diff". Which is entirely unnecessary not just for TUIs, but for the vast majority of GUIs in general, especially for non-DOM-based ones.

As an example, in Claude Code this insanity leads to them spending 16ms "creating a scene" and rendering a couple of hundred of characters on screen: https://x.com/trq212/status/2014051501786931427

Re: Building a TUI is easy now

#182

Post by Tepix »

What‘s the TUI equivalent for mobile apps? Big UI elements and text, iOS 1-6 style, rendered without bitmap graphics?

I.e. something that is lightweight, lightning fast, great to use with just a thumb or so and looks a bit boring and dated, yet also inviting?

Re: Building a TUI is easy now

#183

Post by baq »

troupo wrote: post #181
baq wrote: post #161

Earlier quoted context omitted.

That’s not a TUI, that’s a CLI. Any stateful UI needs a state management backend and a rendering frontend, React isn’t a bad choice for the former.

React is not, and has never been a "state management backend". There are about a million other ways of doing state management than retrofitting it into both React and TUI. Parent comment talks about using React for reconsilliation which is React-speak for "we take a diff between current state of UI and new state of UI, and apply that diff". Which is entirely unnecessary not just for TUIs, but for the vast majority of…

Never said what CC is doing is right. Using React for knowing what to render is good enough for state management for me, that they can’t or won’t figure out how to emit less escape sequences than they need to (which is a solved problem for 40 or 50 years now in windowing UIs) is a different thing.

For the record I can’t stand CC flickering and general slowness and ditched Claude subscription entirely.

Re: Building a TUI is easy now

#184

Post by troupo »

baq wrote: post #183
troupo wrote: post #181

Earlier quoted context omitted.

React is not, and has never been a "state management backend". There are about a million other ways of doing state management than retrofitting it into both React and TUI. Parent comment talks about using React for reconsilliation which is React-speak for "we take a diff between current state of UI and new state of UI, and apply that diff". Which is entirely unnecessary not just for TUIs, but for the vast majority of…

Never said what CC is doing is right. Using React for knowing what to render is good enough for state management for me, that they can’t or won’t figure out how to emit less escape sequences than they need to (which is a solved problem for 40 or 50 years now in windowing UIs) is a different thing. For the record I can’t stand CC flickering and general slowness and ditched Claude subscription entirely.

> Using React for knowing what to render is good enough for state management for me

In TUIs you can re-render the entire screen at hundreds of frames per second. Has nothing to do with state management. Doesn't need React to "figure out what to render".

Again, React is not a state management library. And it's not really applicable to non-DOM rendering approaches.

Re: Building a TUI is easy now

#185

Post by charcircuit »

troupo wrote: post #181
baq wrote: post #161

Earlier quoted context omitted.

That’s not a TUI, that’s a CLI. Any stateful UI needs a state management backend and a rendering frontend, React isn’t a bad choice for the former.

React is not, and has never been a "state management backend". There are about a million other ways of doing state management than retrofitting it into both React and TUI. Parent comment talks about using React for reconsilliation which is React-speak for "we take a diff between current state of UI and new state of UI, and apply that diff". Which is entirely unnecessary not just for TUIs, but for the vast majority of…

That post doesn't say that it takes 16ms to create a scene and have the terminal rasterize and try and present it. That's just the budget they have. It is the upper bound they have to work with.

For example Claude Code could emit a strange symbol and if the terminal has to go and load a font from disk to be able to rasterize something that can eat into the budget and prevent the terminal from having a smooth frame rate by causing a frame drop.

Re: Building a TUI is easy now

#186

Post by charcircuit »

LAC-Tech wrote: post #130
charcircuit wrote: post #121

Earlier quoted context omitted.

If the render is already made in JavaScript it makes sense to reuse react as the reconciliation engine instead of building one from scratch.

What is a "reconciliation engine" and why does a TUI need one?

It solves the problem of if the UI changes, what characters on the terminal do we need to update to show the right thing to the user.

Re: Building a TUI is easy now

#187

Post by codethief »

LAC-Tech wrote: post #130
charcircuit wrote: post #121

Earlier quoted context omitted.

If the render is already made in JavaScript it makes sense to reuse react as the reconciliation engine instead of building one from scratch.

What is a "reconciliation engine" and why does a TUI need one?

Just like in GUI, in a TUI you need some mechanism to make the rendering output (the characters) match the internal state of the application.

E.g., the user hit ESC -> internal state is CANCELED/WAIT FOR USER -> internal GUI representation now includes a prompt that asks the user to tell Claude what to do differently -> rendering output actually shows said prompt.

Re: Building a TUI is easy now

#188

Post by dwb »

dwb wrote: post #66
dale_glass wrote: post #58

Earlier quoted context omitted.

I disagree, I think TUIs are a great fit in some problem domains. Think for instance the Debian package configuration dialogs -- they're far more comfortable than the same questions without a TUI, and still work over a serial console if you have to use one. For tools like various kinds of "top", there's many potential tools you can use to the same end and intentionally using one that draws CPU graphs over one that ju…

Sure, I said I understand why people build them. I’ve used a lot of them. And yes with the tools we have you’re right, but I’m more lamenting the wonky, kind of archaic, unintegrated, only-semi-composable toolset that we have. No fundamental reason why you couldn’t deliver more structured UIs directly over SSH or a serial console, it’s just that in this timeline that didn’t happen yet (apart from X forwarding, which…

I found this which is by far the closet to what I’m on about. Imagine this but with inline UI controls too (keyboard-controllable, natch), probably based on Nushell (I like Nushell), and maybe an “alternate display mode” type thing for UIs that want to take over more and not act as a transcript. And, no offence, but more visually appealing and implemented with a common-denominator subset of native UI controls where possible. Clearly the issue is not building it, but adoption. I don’t have an answer for that.

https://github.com/unconed/TermKit

Re: Building a TUI is easy now

#189

Post by zelphirkalt »

syene wrote: post #126
zelphirkalt wrote: post #89

Earlier quoted context omitted.

While you are at it, it would be good, if the post was readable at all, without having to run JS on the page.

It rendered perfectly, without JavaScript, in Emacs EWW.

I used to try EWW sometimes, but it sometimes made whole Emacs crash at unpredictable times, so I stopped trying to use it. But good to know, maybe I will try again in the future, hoping it becomes more stable/safe.

Re: Building a TUI is easy now

#190

Post by codethief »

qingcharles wrote: post #47

Gemini built a nice TUI for me for a DHT scraper project I was coding: https://imgur.com/a/u3KHbDT It was like two-shot, cos the first version had some issues with CJK chars. I was impressed as it would have taken me a bunch of screwing around on lining up all the data etc when I wanted to concentrate on the scraping algorithm, not the pretty bits.

"DHT" as is "distributed hash table"?

(That is indeed a nice TUI.)

Post reply on HN