https://github.com/anthropics/claude-code/issues/769
I locally patched the closed-source CLI npm package but it's not perfect. They would have to switch how their TUI is rendered on their side.
Apparently OpenAI Codex is rust+ratatui which does not have this issue.
https://github.com/jquast/blessed
One reason for the lack of python might be the timing of the TUI renaissance, which I think happened (is happening?) alongside the rise of languages like Go and Rust.
example: `ranger` is written in python and it's freaking slow. in comparison, `yazi` (Rust) has been a breeze.
Edit: Sorry, I meant GIL, not single thread.
You probably mean GIL, as python has supported multi threading for like 20 years.
Idk if ranger is slow because it is written in python. Probably it is the specific implementation.
They also probably mean TUIs, as CLIs don't do the whole "Draw every X" thing (and usually aren't interactive), that's basically what sets them apart from CLIs.
> We originally built Claude Code on Ink, a React renderer for the terminal. [...] Over the past few months, we've rewritten our rendering system from scratch (while still using React).
https://github.com/anthropics/claude-code/issues/769#issueco...
While not universally applicable, it's very convenient during development to focus on State without thinking about View, or focus on View without thinking about State.
The concept itself has nothing to do with the actual renderer: HTML, TUI, or whatever. You can render your state to a text file if you want to.
So the flickering is caused either by a faulty renderer, or by using a render target (terminal) that is incompatible with the UI behavior (frequent partial re-renders, outputting a lot of text etc.)
Any web react project out there will install react AND react-dom, which is the son implementation of react.
It’s how react translates into mobile, web, etc so well.
It defines contracts and packages like react-dom handle th specific implementation.
Using TS, React here doesn’t make sense for stability in the long term. As you can see, even when they replaced Ink and built their own, the problem still exists.
There are other alternatives that are better than whatever Anthropic did such as Bubbletea (Go) or Ratatui (Rust) which both are better suited for this.
Maybe they were thinking more about job security with TypeScript over technical correctness and a robust implementation architecture and this shows the lack of it.
We moved from the go+bubbletea based TUI which had performance and capability issues to an in-house framework (OpenTUI) written in zig+solidjs
Good grief get me off this sloppy ride.
Should it be solved by now? Yes. If anyone on the team is dogfooding it in a typical tmux environment, its painful. But lets give them some leeway here.
To your point about hiring 1000 devs not solving anything: I agree. For a project of this scope, you’re probably going to peak at one or two 3 person teams with at least one principal dev per team with deep experience in the tech stack and in architecting/building TUIs in general. I would hope their devs are making a relatively lucrative salary too, to attract talent.
I have no idea what the internal structure is so this is just pure speculation: judging by the backlog of issues on their GH, they could use better community management and developer relations. I suspect they’re riding on the existing hype/community interest to fulfill these functions but that only provides a piece of the puzzle.
I think thats probably 1 team short, but I agree on the order of magnitude. So if we assume 12 devs, how long do we think its going to take to fix 5k github issues lol?
Again, I 100% agree the flicker bug should be at the top of the list. And I agree their products in general are riddled with bugs. But Im just saying I can understand the situation even if I think this specific bug should have been fixed already if they were regularly using a setup that runs into it (which I have to assume they arent).
if Amodei hadn't said "90% of code will be written by AI", at least I wouldn't call them hypocrites, but the fact that the company that makes such wild claims can't fix a freaking flicker and scroll issue until an indie-dev steps in just shows how far behind their product is from their claims.
I have CC and use many models with it (Codex in CC, try it!), but I won't let Anthropic "lecture" us about how "the roots of the problem go deep". Literally no other CLI tool has these issues: opencode, codex, gemini, droid, etc.
And we solved this problem over 30 years ago? Ncurses was made for this. The buffer is kept in memory, you hit page-up and it renders the previous page, page-down and it renders the next page, let it roll and it renders each successive page as a stream, or just the last page, etc.
I’m starting to think that the reason why anthropic doesn’t open source Claude code isn’t due to competitive reasons, it’s because they don’t want people to see what a mess their code base is.
Maybe they bought Bun to increase the rate of flickering so that the text looks solid again