Exactly, thank goodness it's still a bit rubbish in some aspects

I said relatively simple. It is mostly an API interface with Anthropic models, with tool calling on top of it, very simple input and output.

The tool is absolutely fantastic coding assistant. That's why I use it.

The amount of non-critical bugs all over the place is at least a magnitude larger than of any software I was using daily ever.

Plenty of built in /commands don't work. Sometimes it accepts keystrokes with 1 second delays. It often scrolls hundreds of lines in console after each key stroke Every now and then it crashes completely and is unrecoverable (I once have up and installed a fresh wls) When you ask it question in plan mode it is somewhat of an art to find the answer because after answering the question it will dump the whole current plan (free screens of text)

And just in general the technical feeling of the TUI is that of a vibe coded project that got too big to control.

what about if management gives them a reason? You can think of which those can be.

Okay, and Windows is by far the most popular desktop operating system.

Discussions are pointless when the parties are talking past each other.

So, there are only two types of companies: ones that have constant downtime, and ones that have constant downtime but hide it, right?

if I had a dollar for each time I heard “until they fix it in short time” I’d have Elon money

interesting

You should elaborate. What are your criteria and why do you think they should matter to actual users?

IMO diffing might have made sense to do here, but that's not what they chose to do.

What's apparently happening is that React tells Ink to update (re-render) the UI "scene graph", and Ink then generates a new full-screen image of how the terminal should look, then passes this screen image to another library, log-update, to draw to the terminal. log-update draws these screen images by a flicker-inducing clear-then-redraw, which it has now fixed by using escape codes to have the terminal buffer and combine these clear-then-redraw commands, thereby hiding the clear.

An alternative solution, rather than using the flicker-inducing clear-then-redraw in the first place, would have been just to do terminal screen image diffs and draw the changes (which is something I did back in the day for fun, sending full-screen ASCII digital clock diffs over a slow 9600baud serial link to a real terminal).

When doing advanced terminal UI, you might at some point have to layout content inside the terminal. At some point, you might need to update the content of those boxes because the state of the underlying app has changed. At that point, refreshing and diffing can make sense. For some, the way React organizes logic to render and update an UI is nice and can be used in other contexts.

Only in the same way that the pixels displayed in a browser are not a tree structure that you can diff - the diffing happens at a higher level of abstraction than what's rendered.

Diffing and only updating the parts of the TUI which have changed does make sense if you consider the alternative is to rewrite the entire screen every "frame". There are other ways to abstract this, e.g. a library like tqmd for python may well have a significantly more simple abstraction than a tree for storing what it's going to update next for the progress bar widget than claude, but it also provides a much more simple interface.

To me it seems more fair game to attack it for being written in JS than for using a particular "rendering" technique to minimise updates sent to the terminal.

The "UI" is indeed represented in memory in tree-like structure for which positioning is calculated according to a flexbox-like layout algo. React then handles the diffing of this structure, and the terminal UI is updated according to only what has changed by manually overwriting sections of the buffer. The CLI library is called Ink and I forget the name of the flexbox layout algo implementation, but you can read about the internals if you look at the Ink repo.

Opencode wrote their own tui library in zig, and then build a solidjs library on top of that.

https://github.com/anomalyco/opentui

Those Rust libraries have existed for some time:

- https://github.com/ratatui/ratatui

- https://github.com/ccbrown/iocraft

- https://crates.io/crates/dioxus-tui

and why do they need react...

I guess with ~50 years of CPU advancements, 3-4 seconds for a TUI to open makes it seem like we lost the plot somewhere along the way.

This is exactly the type of thing that AI code writers don't do well - understand the prioritization of feature development.

Some developers say 3-4 seconds are important to them, others don't. Who decides what the truth is? A human? ClawdBot?

Because when the agent is taking many seconds to minutes, I am starting new agents instead of waiting or switching to non-agent tasks

Anyone that knows a bit about terminals would already know that using React is not a good solution for TUI. Terminal rendering is done as a stream of characters which includes both the text and how it displays, which can also alter previously rendered texts. Diffing that is nonsense.

Thats pretty interesting looking, thanks!

Yes it's people using bad tools on underpowered machines as far as I have seen