Comment by selcuka

Comment by selcuka 3 days ago

15 replies

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 2 days ago

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 3 days ago

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

  • someguyiguess 3 days ago

    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 3 days ago

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

crgwbr 3 days ago

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

  • someguyiguess 3 days ago

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

someguyiguess 3 days ago

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

  • mike_hearn 2 days ago

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

    • reissbaker 2 days ago

      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 a day ago

        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 2 days ago

      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 2 days ago

        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.

reissbaker 2 days ago

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.