3 ms·

I love Claude Code, but how they made the TUI is just plain stupid. Not how it looks, but you know, the React part.

stingraycharles 8mo ago
It’s a very cumbersome UI that feels extremely bloated. Especially if you have a lot of text you want to scroll over — eg i want to see the details of the last X exchanges - it just performs absolutely horribly. It seems like it already was like this from the start, though? I’m not a frontend / TUI dev, but why are these issues so hard to fix?
- wpm 8mo ago
  It's just architected poorly. The job of putting text on a screen fast has been solved for 50 years.
charcircuit 8mo ago
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 8mo ago
  What is a "reconciliation engine" and why does a TUI need one?
  - charcircuit 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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.

It’s a very cumbersome UI that feels extremely bloated. Especially if you have a lot of text you want to scroll over — eg i want to see the details of the last X exchanges - it just performs absolutely horribly. It seems like it already was like this from the start, though? I’m not a frontend / TUI dev, but why are these issues so hard to fix?

wpm 8mo ago
It's just architected poorly. The job of putting text on a screen fast has been solved for 50 years.

charcircuit 8mo ago

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 8mo ago
What is a "reconciliation engine" and why does a TUI need one?
- charcircuit 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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.