> 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
Sorry, I was referring less to the sarcastic elements of this article and more the not sarcastic elements of the Claude Code engineer's post on Twitter / Bsky.
Ah, I understand. Yeah, it read to me as a "good thing" in the sense of "look, it's slow, but it has to be slow". That the complexity was inherent and therefore in some sense good.
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...
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.