What bothers me is that the maintainer quoted at the beginning of the piece is holding this up as almost a virtue: look at this complex thing we've done! But... at its core it's a TUI rendered perhaps what is the most complex and least efficient way possible.
I'm not part of a hypergrowth LLM company, but I do wonder why someone there would take such pride in such inefficient choices.
And as someone who's been using TUIs for ... more years than I'd care to admit ... it's not a particulalry stunning example of one either. I like it fine. It mostly does the job. But it's pretty simple as TUIs go and I could think of ways it could be better.
I've only been using it for a month, but it quickly becomes incredibly laggy. I have to kill it completely and reopen it[1]. I've also had some unique hard locks never before seen on my machine[2], only while it's open and doing things.
I also haven't noticed it outputting anything that would warrant it being more complex than ncurses or the current fashionable equivalent?
[1] /clear helps but not 100%, and the time to get back to lag land increases each time
[2] (Framework 13" AMD 7840U 32GB RAM)
CC has a complex scene rendering pipeline with a 16ms/frame budget. That is much closer to a game engine than a print statement.
this statement is ridiculous and stinks of AI bro superiority
The solution to the flickering is almost certainly trivial and it's in the open source Ink library that Claude Code uses. I outlined it in [1].
Basically, Ink clears lines before rendering the page. That's not how you render TUIs if you don't want them to flicker. All you have to do is write the lines, and include a clear to end-of-line at the end of each one. That means you overwrite what's there and only erase what is removed. Where nothing changes, nothing visibly happens. My comment [1] contains links to the source that needs changing, and I think it would probably be a single-digit line PR to fix it. I'm not going to do so because I neither use Claude Code nor really approve of it.
It's hilarious that the quoted comment framed the issue as if it's rendering to a vsynced framebuffer and only has 16ms to do so, and everyone went with it. That's not how TUIs work at all. It's writing to stdout, ffs.
I mean man, react before rasterizing ? Did any try that before ?
That's clearly not what I would consider a good ad for their technology...
https://github.com/anthropics/claude-code/issues/2327
https://github.com/anthropics/claude-code/issues/2479
https://github.com/anthropics/claude-code/issues/4851
https://github.com/anthropics/claude-code/issues/3105
Latest news is that they've doubled down on it instead.
