5 ms·

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

LAC-Tech 9mo ago
What is a "reconciliation engine" and why does a TUI need one?
- charcircuit 9mo ago
  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.
- codethief 9mo ago
  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.
troupo 9mo ago
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.
- baq 9mo ago
  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.
  - troupo 9mo 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 https://x.com/trq212/status/2014051501786931427
    - baq 9mo ago
      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.
      - troupo 9mo ago
        > 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.
    - charcircuit 9mo ago
      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.

LAC-Tech 9mo ago

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

charcircuit 9mo ago
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.
codethief 9mo ago
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.

troupo 9mo ago

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.

baq 9mo ago
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.
- troupo 9mo 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 https://x.com/trq212/status/2014051501786931427
  - baq 9mo ago
    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.
    - troupo 9mo ago
      > 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.
  - charcircuit 9mo ago
    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.