[selcuka]

For those who don't want to visit X:

    Most people's mental model of Claude Code is that "it's just a TUI" but it should really be closer to "a small game engine".
    
    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
    
    We have a ~16ms frame budget so we have roughly ~5ms to go from the React scene graph to ANSI written.

[PeterStuer]

This is just the sort of bloated overcomplication I often see in first iteration AI generated solutions before I start pushing back to reduce the complexity.

Usually, after 4-5 iterations, you can get something that has shed 80-90% of the needless overcomplexification.

My personal guess is this is inherent in the way LLMs integrate knowledge during training. You always have a tradeoff in contextualization vs generalization.

So the initial response is often a plugged together hack from 5 different approaches, your pushbacks provide focus and constraints towards more inter-aligned solution approaches.

[TZubiri]

How ridiculous is it that instead of a command line binary it's a terminal emulator, with react of all things!

[someguyiguess]

Ok I’m glad I’m not the only one wondering this. I want to give them the benefit of the doubt that there is some reason for doing it this way but I almost wonder if it isn’t just because it’s being built with Claude.

[esafak]

Kudos to them for figuring out how to complicate what should have been simple.

[crgwbr]

Implementation details aside (React??), that sounds exactly like “just a TUI”…

[someguyiguess]

Also React?? One of the slowest rendering front-end libraries? Why not use something … I don’t know … faster / more efficient?

[someguyiguess]

Interesting. On first glance that seems over engineered. I wonder what the reason is for doing it that way?

[mike_hearn]

If you don't do it that way then resizing the terminal corrupts what's on screen.

[reissbaker]

Counterpoint: Vim has existed for decades and does not use a bloated React rendering pipeline, and doesn't corrupt everything when it gets resized, and is much more full featured from a UI standpoint than Claude Code which is a textbox, and hits 60fps without breaking a sweat unlike Claude Code which drops frames constantly when typing small amounts of text.

[mike_hearn]

Yes, I'm sure it's possible to do better with customized C, but vim took a lot longer to write. And again, fullscreen apps aren't the same as what Claude Code is doing, which is erasing and re-rendering much more than a single screenful of text.

[matt_kantor]

It's possible to handle resizes without all this machinery, most simply by clearing the screen and redrawing everything when a resize occurs. Some TUI libraries will automatically do this for you.

Programs like top, emacs, tmux, etc are most definitely not implemented using this stack, yet they handle resizing just fine.

[mike_hearn]

That doesn't work if you want to preserve scrollback behavior, I think. It only works if you treat the terminal as a grid of characters rather than a width-elastic column into which you pour information from the top.

[ttoinou]

Vibecoded ?

[Kelteseth]

Claude made it /s

[reissbaker]

Yes yes I'm familiar with the tweet. Nonetheless they drop frames all the time and flicker frequently. The tweet itself is ridiculous when counterpoints like Vim exist, which is much higher performance with much greater complexity. They don't even write much of what the tweet is claiming. They just use Ink, which is an open-source rendering lib on top of Yoga, which is an open-source Flexbox implementation from Meta.