Comment by charcircuit
8 hours 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.
8 hours 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.
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.
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
3 replies →