[javcasas]

> 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.

[AceJohnny2]

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...

[skydhash]

> This minimizes screen flash. You can't rely on terminals doing double-buffering.

GUI and TUI have different architecture model. Most GUI have have a 2D surface that is redrawn multiple times per second. Double buffering is for decoupling update and render. TUI is a grid of characters that are updated one at a time via an active element, the cursor. Double buffering there is very wrong. Like adding airbags to a bicycle.

There’s a reason you see most old TUI either have an option to redraw the screen (automatically like top, or manually) and those that have a scrolling option allow to scroll by page. The TTY (the underlying concepts) used to be slow and it can be slow today as well (ssh connection). You need to be thoughtful about whole screen updates.

[strix_varius]

lol what? There are definitely ways to make non flashing terminal UIs without this total insanity.

[jaggederest]

ncurses (new curses) was "new" in 1993...

[xiaoyu2006]

Even with that, 1G of RAM usage is still not justified.

[Melatonic]

It's like the Citrix of AI :-D

[stego-tech]

OOF. As a former Citrix admin, I felt that burn in my bones.

An upvote well earned.

[megous]

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.

[skydhash]

> 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.

The TUI mode is a client-server architecture. An analogy would be like an html page where all content is updated server side. Try to do 60 fps and you’ll have flickering as well.

[megous]

No. Fetching pages from remote server will just make the client wait for I/O. That takes 0 CPU load and if the server can't respond at 60fps, lowered redrawing frequency would mean even less CPU load from the terminal redrawing itself.

This does not explain 100% CPU load these harnesses sometimes exhibit.

[skydhash]

If it’s localhost, then it’s just the cpu doing stuff as localhost is a pseudodevice.

[megous]

Localhost is irrelevant.

[Aperocky]

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.

[mapBasketWand]

I love the idea of installing high resolution cameras in the fridge to monitor the ice maker to feed into a vision model that renders digital ice to the exact position of the real ice on the fridge’s giant screen

[Aperocky]

See this is the kind of things I hope I'd be doing when I'm retired, but not when I'm shopping.

[throwway120385]

Or you could... open the door and look inside.

[steve_adams_86]

Sounds like you've got a lot of time on your hands

[asdff]

What, like a poor?

[icepush]

Put a servo on the door and a camera on the front. Train a vision model to recognize when your eyes are looking at the door and automatically open it for you.

Another camera inside will detect when you are done and close it.

[throwway120385]

Think of all the gaze and marketing data we can extract and sell to third parties!

[irishcoffee]

You mean like… a transparent door? Is that the joke?

[yuanBuilds]

Yup. For me, this translates to "we are using Ink, the react-compatible TUI framework to build Claude Code"

[Animats]

What is "frame" in this context? Video frame, or something else?

[javcasas]

> -> rasterizes them to a 2d screen

> We have a ~16ms frame budget so we have roughly ~5ms to go from the React scene graph to ANSI written.

It looks like video frame, full framebuffer, generated and parsed at 60fps. It surprises me they haven't introduced GPU shaders, 16x oversampling and raytracing. Maybe for next release.

[layer8]

The contents of the terminal screen at any given point in time.

[abletonlive]

Care to explain how you'd engineer it instead?

[hungryhobbit]

Why would anyone ever do that? Make Claude do it!

[godelski]

Problem is that Claude did do it. If you look at the leak it's pretty clear there's a lot of LLM code

[stevenhuang]

Not use react native for a cli app for one, lol.

Ratatouille rust cli lib will be a good start.

[mudkipdev]

A reminder that anthropic has great rust/go sdks that they could have written their own tui in.