I'm always surprised that Python doesn't have as good TUI libraries as Javascript or Rust. With the amount of CLI tooling written in Python, you'd think it had better libraries than any other language.

Blessed was a decent one iirc:

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.

Textual looks really nice, but I usually make web apps so I haven’t tried it for anything serious:

https://textual.textualize.io/

Textual is A++. Feels a bit less snappy than Ink, but it makes up in all things with its immense feature-set. Seriously fun building apps of all kinds with this lib.

Textual is cook, but it's maintained by a single guy, and the roadmap hasn't been updated since 2023, https://textual.textualize.io/roadmap/

it has, but python being single threaded (until recently) didn't make it an attractive choice for CLI tools.

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.

> it has, but python being single threaded (until recently) didn't make it an attractive choice for CLI tools.

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.

Even my CC status line script enjoyed a 20x speed improvement when I rewrote it from python to rust.

It’s surprising how quickly the bottleneck starts to become python itself in any nontrivial application, unless you’re very careful to write a thin layer that mostly shells out to C modules.

> You probably mean GIL

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.

I’m using Textual for my TUI needs, it’s very decent.

They started with Ink but have since switched to their own renderer:

> 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...

Thanks for sharing. Very … interesting. Just trying to understand why the heck would React be the best tool here?

React is just an abstraction of a State -> View function.

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.)

I genuinely thought this was satire until I looked it up. I guess it's just to make us webdevs feel at home in the Terminal (ooh, spooky!)

React separates into layers.

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.

Building a react renderer has long been on my wish list of weekend (>1 weekend most likely) projects.

Thats the problem. Some developers want to avoid learning another programming language and use one for everything (including their technologies.)

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.

I’m a fan of Bubbletea, but it is significantly less ergonomic than React. Although I’d argue that if that starts to matter significantly, your TUI is probably too cluttered anyway and you should pare it down.

gemini-cli, opencode are also react based

Opencode uses SolidJS:

    We moved from the go+bubbletea based TUI which had performance and capability issues to an in-house framework (OpenTUI) written in zig+solidjs

https://opencode.ai/docs/1-0/

React?!

Good grief get me off this sloppy ride.

then maybe they should've bought and fixed Ink instead of bun, just saying!

FWIW, Ink is working on an incremental rendering system: they have a flag to enable it. It's currently pretty buggy though unfortunately. Definitely wish Anthropic would commit some resources back to the project they're built on to help fix it...