Comment by troupo
11 hours ago
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
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.
> That post doesn't say that it takes 16ms to create a scene and have the terminal rasterize and try and present it.
So they literally take 16ms to rasterize just a few hundred characters on screen. Of those, 11ms are spent in "React scene graph", and they have 5ms to do the extremely complex task of rendering a few characters.
16ms is an eternity. A game engine renders thiusands if complex 3D objects in less time. You can output text to terminal at hundreds of frames per second in Javascript: https://youtu.be/LvW1HTSLPEk?si=G9gIwNknqXEWAM96
> 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
Into which budget? They spend 11ms "laying out a scene" for a few hundred characters. "Reading something from disk" to render something is a rare event. And that's before we start questioning assumptions about read speeds [1], whether something needs to be rendered in a TUI at 60fps etc.
[1] Modern SSDs can probably load half of their contents into cache before you even begin to see the impact on frames. Unless it's a Microsoft terminal for which they claim they need a PhD to make it fast.
>So they literally take 16ms to rasterize just a few hundred characters on screen
Did you measure this yourself? Where is this number coming from? I am talking about a budget. Even if it takes 1ms total as long as that is under 16 ms that is fine.
More on disk read speed: https://planetscale.com/blog/io-devices-and-latency
--- start quote ---
A typical random read [on a HDD] can be performed in 1-3 milliseconds.
A random read on an SSD varies by model, but can execute as fast as 16μs (μs = microsecond, which is one millionth of a second).
--- end quote ---
If you drop frames in a TUI on a HDD/SDD read for a font file (10-20 KB), you're likely completely incompetent.
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.