You're right - I'll remove that now until we can get it more performant or drop it altogether. This wasn't something we caught during testing. I appreciate the feedback!

> to Commodore 64 level

That’s unfair to C64 which can smooth scroll very well.

FWIW, this page looks just fine in a text-only browser running in textmode, no X11, no Javascript, no CSS, on an old, underpowered computer

Notice how many times Claude Code was mentioned in this blog post nee advertisement?

I disagree, I think TUIs are a great fit in some problem domains.

Think for instance the Debian package configuration dialogs -- they're far more comfortable than the same questions without a TUI, and still work over a serial console if you have to use one.

For tools like various kinds of "top", there's many potential tools you can use to the same end and intentionally using one that draws CPU graphs over one that just displays a number. Graphs are much easier to interpret than a column of numbers.

In many cases they're the optimal choice given some constraint -- like the desire to have minimal dependencies, working over SSH, and being usable without breaking the flow. Yeah, you could make a tunnel to a tool that runs a local webserver and delivers graphs by HTTP, but the ergonomics of that are terrible.

>I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad.

You'd think that, but you'd be wrong. Case in point from Emacs/Vim and the Borland IDEs to Claude, plus all kinds of handy utils from mc and htop to mutt.

>They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely

That's not necessarily bad. Not everything has to be open ended.

Here's why I use them: many modern graphical applications are extremely wasteful. TUIs are typically small, low footprint applications that don't come bundled with a browser or webview. I don't need yet another electron app for every little thing.

Yes, but this kind of dashboard was never going to be accessible anyway. It's a dense visual representation of vast system state with constant real-time fluctuation. Even in a browser, it would be hell to navigate the constantly changing state with a screen reader. And visually increasing the scale and contrast defeats the purpose of the density of the original display.

If you need to support screen readers, your UI would have to be totally different: You should allow the user to snapshot the system state and navigate it. Generate succinct summary text to impart the same sense that a dashboard would to a visual user. "Normal: All systems OK" "Critical: Boeing RPA servers down since 2:17PM PDT and 54 others". Once you've done this work, a CLI tool could expose this just as screen-readable:

    $ cli status
      all systems OK, last outage resolved 2:27 PDT

    $ cli topjob cpu
      117 Boeing RPA, 78% CPU
      434 SAIC PDM, 43% CPU

    $ cli downtime today 117
      Boeing RPA down 10 minutes today, resolved now

> You’re forced to use it exactly the way it was designed and no different

So ... Like all Apple products?

I think I see your point. I've had it in the back of my head too.

Guess it's like the separation between backend and front-end. When the logic is neatly wrapped in a nice API you can potentially get a lot of reusability from that since the API can be integrated into other things with other use cases.

But a TUI probably doesn't naturally come with a separate backend. However, if a cli is built in a non TUI way it is about as flexible as a backend. Output can be streamed into pipes etc.

I can't stream k9s output into a pipe or variable but I can with kubectl.

Would be nice if we could have the cake and eat it here. Can TUI frameworks encourage having it both ways?

> They flatten the structure of a UI under a character stream

Isn't this ... everything though? Even the browser which you mention as better in the next paragraph.

They are GUIs --- just minecraft GUIs. One day, we will rediscover why GUI toolkits exist. The only real advantage TUIs have over GUIs is easy remoting, TBH. Maybe that's enough for people. Otherwise? They're just hair shirts.

Maybe we just need to go all the way: How about a WASM core with a React GUI that runs inside a custom Electron renderer which outputs the TUI? 100% CPU guaranteed. And you'll never find that important piece of information in an all-monochrome wall of text with no icons. Why use a low-level print() when you could improve your productivity with a high-level framework? /s

I suspect that a native GUI, or even something like GPUI or Flutter would be still more performant than TUI's, which are bound by the limitations of emulating terminals.

The question is how many decades each user of your software would have to use it in order to offset, through the optimisation it provides, the energy consumption you burned through with LLMs.

They’re also great for reducing dependencies. What used to be a new dependency and 100 sub-dependencies from npm can now be 200 lines of 0-import JS.

It’s a very cumbersome UI that feels extremely bloated. Especially if you have a lot of text you want to scroll over — eg i want to see the details of the last X exchanges - it just performs absolutely horribly.

It seems like it already was like this from the start, though? I’m not a frontend / TUI dev, but why are these issues so hard to fix?

If the render is already made in JavaScript it makes sense to reuse react as the reconciliation engine instead of building one from scratch.

Kudos to all mc developers!

There are some applications/systems for which certifying bodies forbid the use of web management because of vulnerabilities in both the protocols and the clients and servers. For example, in my daily, several national cyber organizations (NSA, CSE, GCHQ, etc.) have such direction. That's why our main product line is managed using a TUI accessed at the local console or over SSH (with very, very carefully curated SELinux MAC, among other things).

Having said that....

If one is willing to build one's own HTTP server with integrated MAC, etc., and is able to demonstrate mitigations against known vulnerabilities, one may be able to get the certifying bodies on board. Time will tell.

Yes, this is very niche, but TUIs are in general niche.

I like a TUI when I always want an app to run side by side with a CLI. It’s easier to do split windows in a terminal or tmux/zellij panes than to script two separate app windows to stay locked together as a pair. Although, I’d welcome advice as to how to do it better.

I also find TUIs are easier to program for the same reason they’re limited. Fewer human interface aspects in play and it’s not offensive to use the same UI across OSes. (There are still under-the-hood differences across OSes, e.g. efficient file event watching.)

TUIs work well over ssh. Pretty much everything else is a pain in the ass in some capacity, especially when the ssh client is a smartphone.

Gemini made a lovely TUI for my C# project, but afterwards it said it could just spin up a Kestrel web server inside the app instead which would be a much better solution for managing it, which was fair. (I have a line in my Agents to warn me when I specify a way of building something and it's not the ideal solution)

In practice, TUIs tend to have good keybindings, & are readily available right in the place where you're running the command (especially for quick tasks).

TUIs are much easier to run in a container, for one thing. Though, I guess a terminal-based web browser would work for some web apps.

Having a tui file picker in the pipeline can be a powerful technique. Sometimes it just makes sense to have an interface that is slightly more interactive than pre-selecting all the files makes the flow smoother. Being able to put that into a script/alias/whatever is nice.

Other CLI things benefit from this "have a minimal ui interface in the workflow for the one step where it makes sense".

I just added a TUI built on Charm for my custom agent. I primarily use it for two things.

1. Navigating all my chat sessions and doing admin work. It's super fast to push a single key to go in and see what it was about before deleting it.

2. Testing out features and code changes without the web UI / vs code extension complexity.

3. Places where I cannot connect VS Code. I still want to chat and see diffs, a TUI is much easier than a CLI for this.

It also has a CLI, basically three interfaces (CLI, TUI, GUI (vscode/webapp)) to the core features of my personal swiss army knife (https://github.com/hofstadter-io/hof)

I’d be interested to hear more about your project. I’ve heard about other DHT related things like search engines and such using it, but I haven’t explored the space much myself.

Yeah, whenever I hear "Building a TUI is easy now" I imagine someone just discovered ratatui.

Not sure if this satisfies your requirements, but I've gotten Claude Code to run commands in tmux and view their output (including debugging my NeoVim config), so I think that a TUI is at least accessible, even though it would likely bloat the context window far more than a simple CLI.

The article talks about this and in fact talks about how one of the advantages of the TUI was that by combining it with `tmux capture-pane` it ended up easier for Claude to use and iterate on, not harder.

Primary driver for me (finally) learning tmux.

I do.

I want my interfacing with computers to be mouseless and TUIs offer that. I don’t think I’ve run into a GUI, no matter how many hotkeys it has and I know, where I didn’t have to reach for the mouse.

CLI only also requires remembering commands, some of which I use very infrequently, thus need to look up every time I use them.

I think TUIs hold a very nice spot between GUIs and CLI.

I just want a stream, not a TUI. If you can't | it it's not real

Have you tried jjui? It’s pretty nice

Yet ironically getting Claude Code to run at 60fps is way way harder in a TUI? Kinda funny that they optimized for "simple" then footgunned themselves into a client that probably took thousands of man hours to get to a reasonable place for power users.

Charm is what the post submission is using

https://www.textualize.io/

Mobile is not for TUI

If you have a TUI the correct way to support mobile browsers is to 1-shot a React page equivalent. Trying to make the mobile keyboard work for this would be silly.

I think the reference is to all the TUI based coding tools now like opencode.

I think the implicit assumption here is that you are using a terminal-based code editor like neovim... which is not necessarily true.

Hah.

Emacs vterm can do this. It's the only terminal emulator I'm aware of that can, because it seems nobody else cares. It can even backspace and delete all the text selected.

I’ve built textual tuis (as in the Python library) and it responds to clicks just fine.

FWIW, Plan 9 windows work this way. They are just plain UTF-8 buffers with no typewriter emulation. You can edit any text you wish. If you want graphics, the draw device is a 2D graphics compositor you load assets into then issue rendering commands. Text is a draw primitive and easily displayed any way you want, angled, rotated, moving around, colorful. VT emulation is accomplished by vt(1) which does VT over stdio and emulates an ANSI typewriter using the draw device and it works well. You could even write a Plan 9 native TUI That way, just run it under vt(1). But I would not recommend that - go native.

It is possible. Terminals have supported mouse interactions for a long time.

You can use the mouse with TUIs build on the Charm stack

https://github.com/lrstanley/bubblezone

There are a lot of components that resemble things you find in web component libraries

Terminals still have poor keyboard support these days, starting with the Escape key (which should not be ASCII 27 IMO) and various ctrl/shift/alt... key combinations.