> Claude Code is churing out an order of magnitude more instructions than SM64 did, to…diff a terminal panel’s worth of text and draw it.
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
It’s not a good thing, because it’s not a thing. The title is a sarcastic reference to the fact that it uses an order of magnitude more instructions per frame than SM64 did
This accepts the idea that the flickering problem (which is what that comment was about) is to do with slow rendering. It isn't.
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.
What I don't understand is, with all the good tui frameworks/applications existing these days, how was Claude opus/sonnet/whatever not able to help anthropics engineer implement a normal approach ?
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...
moregrist|27 days ago
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.
SCdF|27 days ago
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)
dboon|27 days ago
chrisjj|27 days ago
dpiers|27 days ago
CC has a complex scene rendering pipeline with a 16ms/frame budget. That is much closer to a game engine than a print statement.
Thristle|27 days ago
this statement is ridiculous and stinks of AI bro superiority
jgbuddy|27 days ago
andrewstuart|27 days ago
omnicognate|26 days ago
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.
[1] https://news.ycombinator.com/item?id=46853395
zizon|26 days ago
uargos|27 days ago
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...
flowerthoughts|27 days ago
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.
copilot_king_2|27 days ago