alt Hacker News> For each frame our pipeline constructs a scene graph with React then
> -> layouts elements
> -> rasterizes them to a 2d screen
> -> diffs that against the previous screen
> -> finally uses the diff to generate ANSI sequences to draw
Yup. Overengineering.
Replies
Yup. For me, this translates to "we are using Ink, the react-compatible TUI framework to build Claude Code"
It's product bloat.
It's not recognizing that they are just one building block that should do one thing well, like tmux.
You don't need a computer display on your fridge for the same reason, but Anthropic think you do. You should see virtual ice getting created and they should correspond to the actual ice behind the door - think of how amazing that is!
And it's not even completely a bad idea. make it claude-code-react-beauty of some way to take it off, it would be far more palatable.
React part maybe. The rest is what any TUI that's using ncurses would do. :)
It really bothers me that most of the TUI harnesses are using 100% CPU quite a lot just printing stuff to terminal. Seems ridiculous.
I guess it comes from syntax highlighting/formatting, which is probably not done incrementally, but over the entire so far displayed block of output, recomputed from the beginning for each new streamed in character. Can't imagine anything else causing the rendering to gradually grind to halt when eg. thinking block is open in opnecode and updates get palpably slow as it grows.
Terminal output itself is fast and consumes almost nothing. You can have 60fps terminal apps that update content every frame and that consume almost no CPU time.
What is "frame" in this context? Video frame, or something else?
This is a decades-old design pattern when CPU >> IO. Emacs has been doing just that since the 80s, when people were complaining about "Eight Megs And Constantly Swapping". See "redisplay" [1]
This minimizes screen flash. You can't rely on terminals doing double-buffering.
[1] https://github.com/emacs-mirror/emacs/blob/c29071587c64efb30... or a more user-friendly overview, Daniel Colascione's seminal "Buttery Smooth Emacs", snapshotted at e.g. https://gist.github.com/ghosty141/c93f21d6cd476417d4a9814eb7...