Building a TUI is easy now (opens in new tab)

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.

While I agree with your point, I don't understand why you added:

> here's what Gemini says

Surely, if people care to see LLM generated text, they can do it themselves.

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

To read using Firefox, or any browser/HTML pager, without Javascript or CSS:

   (
   printf 'GET /blog/tuis-are-easy-now HTTP/1.0\r\n'
   printf 'Host: hatchet.run\r\n\r\n'
   )|busybox ssl_client hatchet.run \
   |(echo "<meta charset=utf-8>";grep -o "<p.*</p>") > 1.htm
   firefox ./1.htm

Don't blame my Commodore 64. Once a program is loaded it, runs with 50 or 60hz refresh rate, which is very smooth! Take that! :-)

imagine paying 3k$ for a laptop that can't even handle cubic gradients?

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

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.

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

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

What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore.

I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.

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.

I like that they are integrated into the terminal and stay in the terminal. For most things my terminal multiplexer is essentially my tiling window manager and everything that breaks out of that via its own window is very unergonomic and breaks the structured logic of my workflow. Technically just having a full GUI inside the boundaries of a terminal would be fine for a lot of things. But it's also one of these things where constraints make a lot of things better. Many GUIs are just really bloated and bad. TUIs just do not allow a lot of the sins of modern GUIs.

I agree that they can get very clunky for non text based tasks or anything where you actually need custom text formating.

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.

I don't think most GUIs expose any more structure than TUIs.

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

So ... Like all Apple products?

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.

I had mc on my $20 second hand 286, there are some newer takes on the classic, ranger and nnn come to mind, support for images on the terminal with sixel is pretty neat!

https://github.com/ranger/ranger

https://github.com/jarun/nnn

I had bad feelings on MC, as it's flaky.

Far Manager or Dos Navigator are much better IMO.

Kudos to all mc developers!

I don't use VSCode as my editor, but I found out recently you can open the AI agent sidebar as a separate window, and it's been fantastic - it's mostly replaced Claude Code and other similar TUI tools. It's not quite full integration, but the UI is so much easier to use, because you can be more precise. Rather than having a global "more information" toggle that expands everything like in Claude Code or Pi or whatever, I can specifically inspect the bits of information that I'm interested in. There's two parallel subagents running and one of them is doing unusual things? I can explore exactly what it's doing in more detail.

It helps that VSCode has really improved in the last couple of releases - before then, the features available in Claude Code were useful though that it was worth using despite the baggage, and there's still a handful of things I miss in VSCode. But I think the visual information density and acuity that you can get out of a GUI application is far beyond what you can ever achieve in a TUI, and I think as these tools start reaching something like feature parity, that makes GUIs a lot nicer to use.

The reason is simple: the TUI is the fastest way to provide any form of UI over the file system.

Want to do that with web technologies? You’ll need a browser AND a server or build an app using electron or tauri.

It's LARPing.

Everyone knows all the best programmers are using the command line firing off one line Awk scripts that look like runic incantations occasionally opening vim to do stuff at blazing warp speed.

So the AI tools people build want to take on those trappings to convince people they are serious tools for grown ups.

Ignore that they are basically a full web stack React/CSS conglomeration - feel the L33t hackerness of 'using the command line'. No IDE like a scrub developer you are using a text console, you are a real programmer now.

Yeah. I prefer the smarts of Claude code, but the GitHub copilot UI in vs code is much better, especially for previewing ai diffs.

I was (am) excited for vs codes new native Claude code integration, but it’s pretty buggy and unreliable.

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.

- easy over ssh

- "within bounds" more; designed for actions with keyboard shortcuts and up/down/left/right

- less busy - devs are constrained or less tempted to add animations, css, and other distractions

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

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

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)

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.

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.

What libraries did it use?

"DHT" as is "distributed hash table"?

(That is indeed a nice TUI.)

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.

Mobile is not for TUI

I use TUIs almost daily on my android phone, either some Linux application in Termux or a DOS application in DOSBox. Both have some extra on screen controls to add special keys, and DOSBox in particular allows adding widgets to control things (including invisible buttons, that are fun to add in some cases over parts of the screen in DOS to give an old game or application touch controls).

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 built a TUI application for MS-DOS (well, DOSBox) recently, just using the few functions in MSC 5.1's included graphics library (plus a few simple BIOS calls) and what a joy compared to web interfaces or any GUI library I have used. Having a fixed screen size and known, limited, character set is at least developer-friendly. Of course there existed more advanced libraries as well, but for a simple TUI just a few functions can go a long way.

https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/TOOLS...

Absolutely correct! We've lost a lot along the way.

Author here - I'm also generally skeptical of coding agents, but with the right problem domain and approach they can produce quality output when paired with humans. There was a point in time in the chess world where computer + human was stronger than computer or human alone. I think we're in that era for a handful of applications. Not for things like kernels, browsers, or databases.

> Besides, who is going to maintain that code?

I maintain the code. If Claude gets sunset tomorrow, I'll still be able to maintain and write it - I've already rewritten parts of it.

You could make the same argument for a team member leading a project that you've worked on. Is that code forever required to be maintained by one team member?

Previously the overhead of ensuring code quality when the development process was driven by Claude Code was greater than just writing the code myself. But that was different for this project.

Hi, thanks! To be clear, the demo there is merely a WASM-based Ghostty build which is rendering the TUI on a web page, just so people could try it out without needing to install anything. The actual TUI runs in your terminal. I'm guessing it's the WASM side of things causing the fans to spin, which you wouldn't see locally.

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.

Hah.

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.

This works very well for automated testing from Claude code: https://github.com/pproenca/agent-tui

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.

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

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.

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

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

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

Charm is what the post submission is using

Primary driver for me (finally) learning tmux.

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.

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.