It's somewhat ironic that a web page about performant terminal user interfaces uses gratuitously complex CSS mask compositing and cubic gradients which reduce smooth scrolling on my 1 year-old, high-end Dell XPS laptop (>$3k) to Commodore 64 level (on default 'Balanced' battery mode). While it's pretty, it's also just a very subtle, non-critical background animation effect. Not being a CSS guru myself, here's what Gemini says:
> "Specifically, this is a Scrim or Easing Gradient. Instead of a simple transition between two colors, it uses 16 color stops to mimic a "cubic-bezier" mathematical curve. This creates a smoother, more natural fade than a standard linear gradient, but it forces the browser to calculate high-precision color math across the entire surface during every scroll repaint."
My Firefox smooth scrolls like butter on thousands of pages, so you might want ask your web designer to test on non-Mac, iGPU laptops with hiDPI and consider the performance cost of web pages with always-running subtle background animations in a world of diverse hardware platforms. In case it helps, here's the animation with the gradient layers disabled so you can see all 6,400,000 pixels which are being recalculated every scroll line (https://i.imgur.com/He3RkEu.jpeg).
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!
If you check the source (not the DOM) the actual content is loaded in `<div hidden="" id="S:0"> ...` which is then moved/copied into the proper main content div in the DOM using a JS event it seems.
I used to try EWW sometimes, but it sometimes made whole Emacs crash at unpredictable times, so I stopped trying to use it. But good to know, maybe I will try again in the future, hoping it becomes more stable/safe.
Exactly! The C64 could control where the beam started painting. To move the screen a pixel you just wrote the the x and y offsets to two 8-bit I/O registers. Only after scrolling 7 or 8 pixels you had to copy memory around. I was relatively easy to get this right smoothly and since everything was in sync with the beam it was easy to make tear free.
Shaking effects that did not require memory copy were even easier.
I was green with envy, when I saw how fast and smooth a C64 scrolled some text (iirc it was some machine code monitor). My Amstrad CPC464 had no text mode and the Z80A CPU was clearly overwhelmed with shifting the whopping 16KiB RAM of the graphics buffer or even just rendering a line of text.
Eh, the NES is better because you get two entire screen buffers. The C-64 gives you only one offscreen row or column to repaint every coarse scroll, and the colormap is fixed so you gotta move all of its bytes while racing the beam.
It's not adding more details in this case, it's adding incorrect information. CSS gradients are rasterized once during paint into a bitmap by the browser. Theres no recalculation going on per scroll unless something invalidates the gradient bitmap, and it doesn't matter how many steps the gradient has or how complicated it is.
The real issue is something was causing the container with the gradient to repaint on every scroll.
That’s helpful information but it doesn’t mean the use of Gemini is unwelcome. A human could have rendered the initial analysis too, and then you could have just replied to the human, correcting him or her. Why is the source of the analysis such an issue?
IMO it's because people have learned not to trust LLMs. It's like using AI code generators – they're a useful tool if you know what you're doing, but you need to review the material it produces and verify that it works (in this case, verify that what it says is correct). When they're used as a source in conversations, we never know if the "dev" has "reviewed the code," so to speak, or just copy and pasted.
As for why people don't like LLMs being wrong versus a human being wrong, I think it's twofold:
1. LLMs have a nasty penchant for sounding overly confident and "bullshitting" their way to an answer in a way that most humans don't. Where we'd say "I'm not sure," an LLM will say "It's obviously this."
2. This is speculation, but at least when a human is wrong you can say "hey you're wrong because of [fact]," and they'll usually learn from that. We can't do that with an LLM because they don't learn (in the way humans do), and in this situation they're a degree removed from the conversation anyway.
I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. 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. I get why people build TUIs, but it’s a sorry state of affairs.
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.
Sure, I said I understand why people build them. I’ve used a lot of them. And yes with the tools we have you’re right, but I’m more lamenting the wonky, kind of archaic, unintegrated, only-semi-composable toolset that we have. No fundamental reason why you couldn’t deliver more structured UIs directly over SSH or a serial console, it’s just that in this timeline that didn’t happen yet (apart from X forwarding, which isn’t quite what I’m on about).
I found this which is by far the closet to what I’m on about. Imagine this but with inline UI controls too (keyboard-controllable, natch), probably based on Nushell (I like Nushell), and maybe an “alternate display mode” type thing for UIs that want to take over more and not act as a transcript. And, no offence, but more visually appealing and implemented with a common-denominator subset of native UI controls where possible. Clearly the issue is not building it, but adoption. I don’t have an answer for that.
The difference there, in Debian's case at least, is that there is a distinction between the frontend and the configuration backend; you're probably most familiar with the `newt` frontend, but there's also `text` (for textual entry without using curses or anything), `noninteractive` (for just use the defaults), gnome, kde, teletype, or even 'web' which does not seem to work effectively but is a neat idea regardless.
TUIs which are just TUI views of data you can get otherwise are fine; TUIs which are the only way to interact with something... less so.
I like TUIs, but if given the choice between a TUI or a CLI program, I'd take the latter. You can always create your own interface from it. Better if it's backed by a library.
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.
I’m definitely not advocating more little electron apps, and I’m totally with you on TUI’s benefits. I’m bemoaning the lack of imagination that has ended us up here and not in a situation where we can have, say, a small, low-footprint application that can deliver a more structured UI with minimal dependencies. It’s not an impossibility, it’s not even that difficult to imagine, we just don’t have the exact technology.
The thing is Windows 98 let you throw up a HTML window with almost zero overhead (the OS used the same libraries) and javascript could get data easily from another process via COM etc.
Now like 25 years later, apparently our choices are shipping bespoke copies of Chrome and Node, OR making shit work on an emulated 1981 DEC terminal. Lack of vision is exactly right.
I think for the time being, there's no way to get around writing native UIs to get a native experience. Any sufficiently high level APIs will have to give up something. TUIs for me fill that niche because across any POSIX-compatible interface they will generally work the same, and modern high level languages make cross-compiling to terminals a breeze. Now to write a native UI across Windows, MacOS, Wayland and X11, that's a different story.
I’m happy to give up a lot; I’m not tied to fully-native-looking UIs for the types of things I’m talking about. Totally get that lowest common denominators will feel native nowhere. I just think it’s possible to do a lot better than the current state of TUIs.
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’m not just talking about screen readers, though they are important. I mean “accessible” more generally. Yes you could build a specific UI for each kind of user, but that seems far less likely to cover as many uses as building one UI that is structured, programmatically navigable, etc.
>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.
Funnily, Emacs is getting closer to what I’m after (it’s my main editor).
> That's not necessarily bad. Not everything has to be open ended.
I think it is necessarily bad and everything should be open ended. Bad in the sense of low quality, but if we’re talking about critical accessibility (someone is unable to use your application at all), morally bad too.
How many developers are using VSCode? How does that number compare with Emacs/Vim?
In many ways, GUI was developed as the natural evolution of TUI. X server, with its client-server architecture, is meant to allow you to interact with remote sessions via "casted" GUI rather than a terminal.
Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.
>How many developers are using VSCode? How does that number compare with Emacs/Vim?
How many people eat microwave meals? How many eat gourmet Michelin star dishes?
I don't care "how many use VSCode". My argument Emacs/Vim have great, well loved TUIs. And they are used by a huge number of the most respected coders in the industry. Whether a million React jockeys use VSCode doesn't negate this.
>Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.
Yes, it sells to the masses. Countless food industry scientists aspend many man-hours to develop detrimental ultra-processed crap for a reason too.
The analogy mostly makes a point for snobbishness, but otherwise doesn’t really work. Most people would rather eat meals prepped by a Michelin star cook, but they can only afford microwave meals - whereas EMacs/Vim and VSCode are equally accessible to anyone.
I love emacs but would never compare that with a Michelin meal! On the contrary, emacs is the DIY option that lets you experiment with whatever ingredients you please without judging your choices!
> My argument Emacs/Vim have great, well loved TUIs.
They... are not great. They provide the absolute bare minimum of an UI.
An UI, even a terminal one, is more than a couple of boxes with text in them. Unfortunately, actual great TUIs more or less died in the 1990s. You can google Turbo Vision for examples.
> How many developers are using VSCode? How does that number compare with Emacs/Vim?
Perhaps I'm in some sort of "TUI bubble", but I'd bet good money that Emacs/Vim users outnumber VSCode users by an order of magnitude. But maybe I'm just surrounded by *nix devs.
I agree except about the TUI coolness factor. There really is a lot that’s appealing about TUIs, I agree on that with the other commenters here. I want a better synthesis than what we have.
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.
I don't quite agree with this. Feature discovery is much easier in GUI when most commonly used features are either in the first layer of menu or in standard hotkeys. In the worst case, you would do a search in GUIs that provide them. In CLI / TUI, no such function is present and you would basically have to man and scroll through all possible commands to find it, though I guess grep helps.
You accept search in GUI, but don't in man pages? Scrolling through actions in a tree-like menu structure is ok, but through a tree-like structure in the --help output is not? Feels inconsistent.
The whole benefit of text-based interface is that search, filter and transformation is always available and completely independent of the running program.
I can see the visual discoverability aspect for GUIs, but for the visual layout GUIs and TUIs are on par, the difference is rather in the rendering mechanism: pixel vs. character-based.
I agree about the constraints. My ideal solution would also impose harsh constraints, but would also add just enough structure. I’m also frustrated by each app reinventing the same thing slightly differently.
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've use Claude to make myself a number of little tools and weird apps that only I would want lately. They need to be cross-platform between Linux and Mac and sometimes Windows. The best approaches I've found are Tauri (+Svelte for making layout easier) for lightweight GUIs but for anything more complex I prefer a TUI. The Ratatui framework works very well. A TUI feels like a "real" app as opposed to a glorified webpage. For actually serious software I'd want a native GUI on each platform.
There are so many options for what you describe. E.g. the whole point of Tcl/Tk is to allow easy creation of small little tools and apps. And you can use Tk with Python as well.
A TUI app feels like a native terminal app like I have used for my entire computing life, in DOS and then Linux. Electron apps feel like web apps no matter how good they are. I stopped using 1Password when it became an Electron app and became super janky. Discord, Slack, VS Code, the Signal desktop app, all suck UI-wise compared to actual native Mac apps, which even with Liquid Ass, are still better than using web technology for desktop apps. I know that lowest common denominator cross platform apps make economic sense to develop, whatever. They still suck to use.
No. Good TUI apps are predictable and fast, like good native GUI apps. They follow set patterns. Familiarity and following standard conventions is not just "nostalgia" -- maybe a little is in there -- but it makes apps more usable. And, for cross-platform apps, it's a cross-platform standard. I'd rather have a TUI app following TUI conventions than a cross-platform app that is just a freeform mish-mash. Like, this week I've been making a TUI replacement for Plexamp which has great features but its Mac app is just like a scrolling webpage. If I am going to have a GUI app that is more than a tiny toy or utility I want it to follow each platform's native conventions and use its native GUI components or to not even bother. I will grant that Electron has made strides in terms of properly integrating into each host OS (using the full Mac menu bar, the correct keyboard shortcuts, accessibility features and so on) so the situation is not as bad as it once was. And also, plenty of people use and have used terminal editors and other tools by choice, for years, and not just because they are connecting to remote servers. A keyboard-first interface can be quite fast and they are more natural in TUIs.
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?
Not even close. Apple UIs - despite recent graphical howlers - have excellent accessibility APIs and are regularly praised by people that track such things. I’ve recently been building a macOS app and the UI testing is also based off it. There are apps that allow full keyboard navigation using it. I do agree that the window management side is much less customisable, though, and that does frustrate me.
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
Building a TUI was easy before, especially with the great toolsets for their respective languages BubbleTea / Textualize / Ratatui. And thanks to those frameworks, LLMs can manifest useful tools.
Similar to WebApps, it's only since the November'25 renaissance that I felt I could use them to create TUIs. Once I had that revelation, I started going into my backlog and using it.
I maintain a TUI Charting library, NTCharts. In January, I fixed a bug - totally obvious once identified - that I personally failed to find earlier. But the test harness, prompting, and Gemini got it done [1]. Gemini's spatial understanding was critical in completing the task.
I've been vibe-crafting a local LLM conversation viewing tool called thinkt. After scraping ~/.claude and making a data model, this is the point in PROMPTS.md where I start creating the TUI using BubbleTea. [2].
As LLMs consume all our compute resources and drive up prices for the compute hardware on which we run applications, the silver lining is that LLMs are helpful in implementing tooling without a heavy stack so it will run quickly on a lower-spec computer.
I've achieved 3 and 4 orders of magnitude CPU performance boosts and 50% RAM reductions using C in places I wouldn't normally and by selecting/designing efficient data structures. TUIs are a good example of this trend. For internal engineering, to be able to present the information we need while bypassing the millions of SLoC in the webstack is more efficient in almost every regard.
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.
A very important thing about constraints is that they also liberate. TUIs automatically work over ssh, can be suspended with ctrl-z and such, and the keyboard focus has resulted in helpful conventions like ctrl-R that tend to not be as prominent in GUIs.
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.
When global supply chains are disrupted again, energy and/or compute costs will skyrocket, meaning your org may be forced to defer hardware upgrades and LLMs may no longer be cost effective (as over-leveraged AI companies attempt to recover their investment with less hardware than they'd planned.) Once this happens, it may be too late to draw on LLMs to quickly refactor your code.
If your business requirements are stable and you have a good test suite, you're living in a golden age for leveraging your current access to LLMs to reduce your future operational costs.
In the past week I made 4 different tasks that were going to make my m4brun at full tilt for a week optimized down to 20 minutes with just a few prompts. So more like an hour to pay off not decades. average claude invocation is .3 wh. m4 usez 40-60 watts, so 24x7x40 >> .3 * 10
Would it be that many? Asked AI to do some rough calculation, and it spit that:
Making 50 SOTA AI requests per day ≈ running a 10W LED bulb for about 2.5 hours per day
Given I usually have 2-3 lights on all day in the house, that's like 1500 LLM requests per day (which sounds quite more than I do).
So even a month worth of requests for building some software doesn't sound that much. Having a local beefy traditional build server compling or running tests for 4 hours a day would be like ~7,600 requests/day
Yes... But the machines in those data centres don't get there without the companies who put them there. You get no tasks for no minutes, without the infrastructure, and so the infrastructure does actually have to be part of the environmental impact survey.
Is that true? Because that's indeed FAR less than I thought. That would definitely make me worry a lot less about energy consumption (not that I would go and consume more but not feeling guilty I guess).
A H100 uses about 1000W including networking gear and can generate 80-150 t/s for a 70B model like llama.
So back of the napkin, for a decently sized 1000 token response you’re talking about 8s/3600s*1000 = 2wh which even in California is about $0.001 of electricity.
With batched parallel requests this scales down further. Even a MacBook M3 on battery power can do inference quickly and efficiently. Large scale training is the power hog.
I’m not really worried about energy consumption. We have more energy falling out of the sky than we could ever need. I’m much more interested in saving human time so we can focus on bigger problems, like using that free energy instead of killing ourselves extracting and burning limited resources.
Especially considering that suddenly everyone and their mother create their own software with LLMs instead of using almost-perfect-but-slighty-non-ideal software others written before.
I think mc (Midnight Commander) is still one of the best TUIs available - it's very close in capability to the GUI versions (like Double Commander) and it has the benefits of tuis - like that you can run it on a remote system.
It looks outdated, but I'm actually now working on a new skin that will hopefully be included in the next release of mc.
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!
I genuinely don't understand the TUI obsession for LLM applications.
Go watch copilot drive VS2026 if you've never seen it in action. There is no way you are going to be able to communicate this same amount of information via plain text in the same amount of time. I can catch a lot of bad stuff mid-flight because I can actually multitask my UI and click into diffs as files are edited in real time.
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.
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.
Actual hackers will use AWK and anything else... over Acme under 9front which is pretty much graphical, and current Emacs users will use a graphical setup with tons of keybindings, commands and Elisp functions. The best of both worlds. You have both the scriptability, keyboard shortcuts and mouse for selection and quick pointng.
I don't disagree. However, the TUI seems to have become the final destination for some major AI vendors. This doesn't look like a stepping stone to me.
I don't see any real advantage of TUIs over web forms or GUIs for the same thing.
I do like CLIs though, especially the ones that are properly capable of working in pipelines. Composing a pipeline of simple command-line utilities to achieve exactly what you want is very powerful.
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.)
> 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.
Did you try some tiling window managers and decided you did not like that?
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)
> 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
And that helps? I tried that a while ago and it very often said this is not a good way of doing something even though it was objectively the best way of doing something. I removed it after a while because it was too random.
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).
They can, but don't always. I've used some where you have to smash the TAB key 50 times go move linearly through all the fields and controls. If there are well-implemented navigation keys, yes they it can be very efficient.
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)
It was like two-shot, cos the first version had some issues with CJK chars.
I was impressed as it would have taken me a bunch of screwing around on lining up all the data etc when I wanted to concentrate on the scraping algorithm, not the pretty bits.
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.
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?
Just like in GUI, in a TUI you need some mechanism to make the rendering output (the characters) match the internal state of the application.
E.g., the user hit ESC -> internal state is CANCELED/WAIT FOR USER -> internal GUI representation now includes a prompt that asks the user to tell Claude what to do differently -> rendering output actually shows said prompt.
No, no it makes exactly zero sense to have a "reconciliation engine" or React in a TUI. There's nothing to reconcile. You can just output a stream of characters as fast as they appear.
React is not, and has never been a "state management backend".
There are about a million other ways of doing state management than retrofitting it into both React and TUI.
Parent comment talks about using React for reconsilliation which is React-speak for "we take a diff between current state of UI and new state of UI, and apply that diff". Which is entirely unnecessary not just for TUIs, but for the vast majority of GUIs in general, especially for non-DOM-based ones.
As an example, in Claude Code this insanity leads to them spending 16ms "creating a scene" and rendering a couple of hundred of characters on screen: https://x.com/trq212/status/2014051501786931427
That post doesn't say that it takes 16ms to create a scene and have the terminal rasterize and try and present it. That's just the budget they have. It is the upper bound they have to work with.
For example Claude Code could emit a strange symbol and if the terminal has to go and load a font from disk to be able to rasterize something that can eat into the budget and prevent the terminal from having a smooth frame rate by causing a frame drop.
> That post doesn't say that it takes 16ms to create a scene and have the terminal rasterize and try and present it.
So they literally take 16ms to rasterize just a few hundred characters on screen. Of those, 11ms are spent in "React scene graph", and they have 5ms to do the extremely complex task of rendering a few characters.
16ms is an eternity. A game engine renders thiusands if complex 3D objects in less time. You can output text to terminal at hundreds of frames per second in Javascript: https://youtu.be/LvW1HTSLPEk?si=G9gIwNknqXEWAM96
> and if the terminal has to go and load a font from disk to be able to rasterize something that can eat into the budget
Into which budget? They spend 11ms "laying out a scene" for a few hundred characters. "Reading something from disk" to render something is a rare event. And that's before we start questioning assumptions about read speeds [1], whether something needs to be rendered in a TUI at 60fps etc.
[1] Modern SSDs can probably load half of their contents into cache before you even begin to see the impact on frames. Unless it's a Microsoft terminal for which they claim they need a PhD to make it fast.
>So they literally take 16ms to rasterize just a few hundred characters on screen
Did you measure this yourself? Where is this number coming from? I am talking about a budget. Even if it takes 1ms total as long as that is under 16 ms that is fine.
They literally complain about that in yhe tweet I linked. That they spend 11 ms in React and only have 5ms to do the impossibly hard task of outputting a few characters on screen.
> Even if it takes 1ms total as long as that is under 16 ms that is fine.
How is it fine when you can re-render the entire terminal in microseconds (I also linked a demo for that, too), and they take 11 milliseconds just "constructing React scene"?
It doesn't matter if they take 12ms to render or 16ms. You're completely missing the point.
Never said what CC is doing is right. Using React for knowing what to render is good enough for state management for me, that they can’t or won’t figure out how to emit less escape sequences than they need to (which is a solved problem for 40 or 50 years now in windowing UIs) is a different thing.
For the record I can’t stand CC flickering and general slowness and ditched Claude subscription entirely.
> Using React for knowing what to render is good enough for state management for me
In TUIs you can re-render the entire screen at hundreds of frames per second. Has nothing to do with state management. Doesn't need React to "figure out what to render".
Again, React is not a state management library. And it's not really applicable to non-DOM rendering approaches.
Indeed. Over a few days of iterations I had this TUI built for fast full-text search of Claude Code or Codex sessions using Ratatui (and Tantivy for the full-text search index). I would never have dreamed of this pre coding agents.
Building TUIs was already super easy in 1990 with Turbo Vision and Clipper on MS-DOS, with compiled languages (TP, xBase), using super fast build times on systems running at 10 Mhz, within 640 KB.
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.
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.
Hi everyone, I enjoyed building this TUI for myself and wanted to write down how I did it. I appreciate all the thoughts and feedback! The web app is our main investment, but I think there's a slice of developers who really like to interact with TUIs, so I'm going to keep working on it.
For the demo at https://tui.hatchet.run, to answer some messages asking about it: I built this with the fantastic ghostty-web project (https://github.com/coder/ghostty-web). It's been a while since I've used WASM for anything and this made it really easy. I deployed the demo across six Fly.io regions (hooray stateless apps) to try to minimize the impact of keystroke latency, but I imagine it's still felt by quite a few people.
> Notably this was the first time I felt that using Claude Code for something non-arbitrary was significantly faster than doing it myself
Well, it is like code completion on a higher level.
I still don't like this approach. Besides, who is going to maintain that code?
Such code will probably forever be required to be maitnained via Claude. So no
humans involved. Just autogenerated stuff. I dislike this idea a lot.
Humans are slower, ok, but they built excellent software before Claude. What is
coming next? Claude Linux-like Kernel? Top500 supercomputers will run it?
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.
Turbo C++ was peak TUI. Even on hardware thousands of times slower than today it had that instantaneous wired-to-the-machine feeling that I rarely experience today.
I too enjoy the charm TUI libraries, and have been using them to build a settlers of Catan game[0]. And some features are really cool, like different colors depending on dark/light theme.
They have a bunch of functions that concatenate strings, which may not be very efficient compared to using string.builders, but I haven't yet had performance problems.
However I haven't had such a great experience with AI, IMO they're bad at ASCII art.
Hey! This looks great, and I appreciate the effort! But just opening the page at https://tui.hatchet.run/ causes my (admittedly old Intel i7 9700K) to spin up its fans and consume >30% of the CPU without me even doing anything. I don't think a TUI should do that.
I was also intrigued by it being a lot of Go dependencies as I have developed a bit of a fancy for this language recently.
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.
I knew this would be ANOTHER ai glazing post before even clicking. I think we must specify if a post is about AI in titles. Another "I built X" with AI really brings nothing to the table, and I've seen a few users agree with me on this.
Here's a similar situation, a submission called "webdev is fun again", and what you find inside is just gushing about how good AI is. Genuinely what value does it bring? I think this phenomenon is literally "clickbaiting" but on hackernews
Other users from here seem to see the same thing that I do:
Big reason why TUIs were popular in the first place is because they are so much simpler to build. Compare ncurses to GTK/Qt, they are completely different leagues. One of my pet ideas is to build a ncurses compatible/style library that skips terminal layer and instead renders directly to Wayland, kinda getting the simplicity of ncurses without dragging all the legacy junk with it.
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.
Building TUIs might be easy now but building good user experience on a TUI is feels harder than ever has been to me. The modern libraries make a lot of things easy but we are currently pushing terminals far beyond what they were designed for.
Claude Code et.al. are good examples of that. Diffs, user approval flows, non-linear flows in general and a ton of text buffered are all elements that we know really well how to handle in web interfaces but are challenging for the terminal.
TUIs are great fun and Claude can make beautiful ones with a little ratatui action super fast. However, the downside of these are that you can't use them with Claude Code so while I have a few I prefer to also have a prompt-response CLI function since that's better for lots of things.
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.
Yeah, this is my main way of using Claude Code for anything complex – a REPL or bash window in tmux, and with Claude running commands there. That lets me easily browse through anything that's happened in a UI I'm used to, or manually intervene if needed.
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.
The cursor CLI was a great springboard for me to make my own frontend to prompt from, I would never use it though god, I implemented git, difs, and chat histories, so i can use it easily from my phone with tailscale. It picks up on my rules and can grep my project, so easy. https://imgur.com/a/HZOEvr7
I haven’t done much with Claude code yet but I’ve watched some rather recent videos of other people leverage it to get work done and I couldn’t help thinking, are we going to end up with a similar UI but with fully deterministic “agents” at the end of this hype cycle.
All of the skills I saw demonstrated were deterministic. So does this end in a Functional Core, Imperative Shell scenario that looks like a Terraform Plan and a search engine-style natural language processor out front?
Dagger has a really nice TUI built on Charm. It reads OTEL to create an interactive tree for your builds and containers. If you have cloud setup, it will also push that all to a webapp interface where you can share and navigate in perpetuity. This works for both CI and local runs, super cool for sharing links to failed builds during dev, even while the dev's local build is still running
If it was so easy Anthropic wouldn't have messed up CC for so long. The author takes for granted the availability of good off-the-shelf TUI libraries for his chosen language.
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.
VS Code with the Vim extension is largely mouseless
I use the TUI from a terminal tab in VS Code, my agent works with that and the custom extension with a webapp based interface, seamlessly and concurrently
GUIs, TUIs, and PR/kanban all make sense in different situations. We'll all use at least two of them on regular basis for coding agents.
> VS Code with the Vim extension is largely mouseless
It's also easily mouseless without any Vim or like extension. I never mouse in it, having given intuitive-to-me keychords to all the various moves I need to make beyond the standard stuff.
Claude Code has done a good job of building a tui MUD client (I couldn’t find one I liked), and then building a GUI version using Tauri where all the config is shared, so you can run it as either a GUI (on any platform) or TUI. Happy with it so far, and I personally use both TUI mode or GUI mode (with floating panes) depending on what I’m doing.
I was working on a fairly niche thing, a library of crossplane compositions written in KCL and thought it would be nice to have a TUI so i could browse through them and see the rendered yaml as claude was working on it. I asked claude code to write it with python and textual and it one shotted it in about two minutes including a test suite.
With Claude, I built a TUI for managing QEMU/KVM VMs (Rust with ratatui.) Solves a lot of problems I had with virt-manager, so I made it a FOSSS project. https://www.vm-curator.org.
The problem with TUI's, that we have all Stockholm syndrom'd ourselves, is that I can't use the mouse cursor to click to the position on the screen and edit the command line.
possible isn't the same as supported and working. A non-terminal hunt-and-peck typer sits down and is presented with a terminal, what's the second that happens when they're typing? they make a mistake and try to click on the word they misspelled, and it doesn't work.
That’s a very specific gripe to make. So specific that you have to acknowledge it’s not going to be a deal breaker for everyone. Which makes me wonder why you’d use the “Stockholm Syndrome” argument — assuming you used it in good faith and not just because you wanted to sound edgy (or some approximate synonym of)
> It's a thing that confuses every single person the first time they touch a terminal!
I get that. But it doesn’t mean those that prefer the terminal have Stockholm Syndrome.
The terminal is a UI optimised for keyboard entry. So of course mouse input to move the caret wouldn’t be something that is prioritised to support.
Again, that’s not Stockholm Syndrome; it’s just a different workflow.
> Could do without the diction-based ad hominem.
You’re the one making ad hominem attacks by saying CLI users suffer from “Stockholm Syndrome”. That was your comment not mine.
I said I was willing to take your comment in good faith. Which isn’t a personal attack.
I’m really not interesting in meta arguments nor using intentionally antagonistic language. And if you continue to communicate this way then I will just ignore you.
A terminal emulator in a GUI environment such as Linux is expected to play nice with the GUI and support mouse-based select, copy and paste, as well as being a terminal emulator, and this means that the terminal itself is consuming mouse events to support text selection.
If you wanted to write a shell that has mouse support you could certainly do so, and this would be based on sending escape codes to the terminal to tell it to return mouse events as input rather than let the terminal consume them itself. The shell could then itself support the clipboard if it wanted to, as well as support mouse editing.
I just googled it, and apparently "fish shell" does exactly this, but your hypothetical user is more likely to stumble upon a bash shell which is letting the terminal emulator consume the mouse events and support copy and paste.
Readline is one of the oldest libraries available on modern systems.
So old that Charm, the framework featured in this article, is written in a programming language that was decades away from conception back when readline was first released.
Comparing modern TUIs to readline is like comparing an analogue rotary phone to a smartphone.
Readline is also no longer the default experience for your average new user since macOS switched to Zsh many years ago and Microsoft will push Powershell over WSL in the row documentation.
I do get the point you’re trying to make. But it’s a pretty weak argument give the age of your examples.
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.
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.
It runs poorly, loses keystrokes, and easily gets bogged down with too much terminal input.
I don't want candy coated monospace ASCII graphics. I want something fast and functional. The graphics are _entirely_ secondary. You've missed the point of what a TUI is.
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.
It’s not easy to build a good tui though. Like fe compare Claude code and opencode. Opencode is an atrocious approximation of a window system as a tui.
I think pi-mono (https://github.com/badlogic/pi-mono) is pretty close.
The extensibility is wonderful and a much better fit for how I work compared to Claude Code.
Alex,
It's somewhat ironic that a web page about performant terminal user interfaces uses gratuitously complex CSS mask compositing and cubic gradients which reduce smooth scrolling on my 1 year-old, high-end Dell XPS laptop (>$3k) to Commodore 64 level (on default 'Balanced' battery mode). While it's pretty, it's also just a very subtle, non-critical background animation effect. Not being a CSS guru myself, here's what Gemini says:
> "Specifically, this is a Scrim or Easing Gradient. Instead of a simple transition between two colors, it uses 16 color stops to mimic a "cubic-bezier" mathematical curve. This creates a smoother, more natural fade than a standard linear gradient, but it forces the browser to calculate high-precision color math across the entire surface during every scroll repaint."
My Firefox smooth scrolls like butter on thousands of pages, so you might want ask your web designer to test on non-Mac, iGPU laptops with hiDPI and consider the performance cost of web pages with always-running subtle background animations in a world of diverse hardware platforms. In case it helps, here's the animation with the gradient layers disabled so you can see all 6,400,000 pixels which are being recalculated every scroll line (https://i.imgur.com/He3RkEu.jpeg).
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!
While you are at it, it would be good, if the post was readable at all, without having to run JS on the page.
It rendered perfectly, without JavaScript, in Emacs EWW.
I think perhaps Emacs does not support the `hidden` attribute?
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
If you check the source (not the DOM) the actual content is loaded in `<div hidden="" id="S:0"> ...` which is then moved/copied into the proper main content div in the DOM using a JS event it seems.
It must have sent it differently if the browser reports it can’t do JavaScript.
I used to try EWW sometimes, but it sometimes made whole Emacs crash at unpredictable times, so I stopped trying to use it. But good to know, maybe I will try again in the future, hoping it becomes more stable/safe.
I don’t think EWW has ever made my Emacs crash. I wanna say I’ve been using it regularly since Emacs 27.
[flagged]
[dead]
> to Commodore 64 level
That’s unfair to C64 which can smooth scroll very well.
Exactly! The C64 could control where the beam started painting. To move the screen a pixel you just wrote the the x and y offsets to two 8-bit I/O registers. Only after scrolling 7 or 8 pixels you had to copy memory around. I was relatively easy to get this right smoothly and since everything was in sync with the beam it was easy to make tear free.
Shaking effects that did not require memory copy were even easier.
I owned a C64. Remember how buttery smooth the interfaces of those '80s computers were?
I was green with envy, when I saw how fast and smooth a C64 scrolled some text (iirc it was some machine code monitor). My Amstrad CPC464 had no text mode and the Z80A CPU was clearly overwhelmed with shifting the whopping 16KiB RAM of the graphics buffer or even just rendering a line of text.
CPC allows some level of smooth scrolling, albeit not as good as C64. Lack of a text mode is a problem too as you said.
Not Apples. But Amigas, omg those were smooth.
fewer layers between software and hardware...
Not by repainting the whole screen every frame!
Modern browsers don’t repaint the whole screen every frame either.
Eh, the NES is better because you get two entire screen buffers. The C-64 gives you only one offscreen row or column to repaint every coarse scroll, and the colormap is fixed so you gotta move all of its bytes while racing the beam.
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.
It's a clearly marked quote that adds more details. It's perfectly fine.
It's not adding more details in this case, it's adding incorrect information. CSS gradients are rasterized once during paint into a bitmap by the browser. Theres no recalculation going on per scroll unless something invalidates the gradient bitmap, and it doesn't matter how many steps the gradient has or how complicated it is.
The real issue is something was causing the container with the gradient to repaint on every scroll.
That’s helpful information but it doesn’t mean the use of Gemini is unwelcome. A human could have rendered the initial analysis too, and then you could have just replied to the human, correcting him or her. Why is the source of the analysis such an issue?
IMO it's because people have learned not to trust LLMs. It's like using AI code generators – they're a useful tool if you know what you're doing, but you need to review the material it produces and verify that it works (in this case, verify that what it says is correct). When they're used as a source in conversations, we never know if the "dev" has "reviewed the code," so to speak, or just copy and pasted.
As for why people don't like LLMs being wrong versus a human being wrong, I think it's twofold:
1. LLMs have a nasty penchant for sounding overly confident and "bullshitting" their way to an answer in a way that most humans don't. Where we'd say "I'm not sure," an LLM will say "It's obviously this."
2. This is speculation, but at least when a human is wrong you can say "hey you're wrong because of [fact]," and they'll usually learn from that. We can't do that with an LLM because they don't learn (in the way humans do), and in this situation they're a degree removed from the conversation anyway.
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:
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 think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. 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. I get why people build TUIs, but it’s a sorry state of affairs.
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.
Sure, I said I understand why people build them. I’ve used a lot of them. And yes with the tools we have you’re right, but I’m more lamenting the wonky, kind of archaic, unintegrated, only-semi-composable toolset that we have. No fundamental reason why you couldn’t deliver more structured UIs directly over SSH or a serial console, it’s just that in this timeline that didn’t happen yet (apart from X forwarding, which isn’t quite what I’m on about).
Yes. Composable GUI is what we're after.
Yes!
I found this which is by far the closet to what I’m on about. Imagine this but with inline UI controls too (keyboard-controllable, natch), probably based on Nushell (I like Nushell), and maybe an “alternate display mode” type thing for UIs that want to take over more and not act as a transcript. And, no offence, but more visually appealing and implemented with a common-denominator subset of native UI controls where possible. Clearly the issue is not building it, but adoption. I don’t have an answer for that.
https://github.com/unconed/TermKit
The difference there, in Debian's case at least, is that there is a distinction between the frontend and the configuration backend; you're probably most familiar with the `newt` frontend, but there's also `text` (for textual entry without using curses or anything), `noninteractive` (for just use the defaults), gnome, kde, teletype, or even 'web' which does not seem to work effectively but is a neat idea regardless.
TUIs which are just TUI views of data you can get otherwise are fine; TUIs which are the only way to interact with something... less so.
I like TUIs, but if given the choice between a TUI or a CLI program, I'd take the latter. You can always create your own interface from it. Better if it's backed by a library.
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.
I’m definitely not advocating more little electron apps, and I’m totally with you on TUI’s benefits. I’m bemoaning the lack of imagination that has ended us up here and not in a situation where we can have, say, a small, low-footprint application that can deliver a more structured UI with minimal dependencies. It’s not an impossibility, it’s not even that difficult to imagine, we just don’t have the exact technology.
I'm with you.
The thing is Windows 98 let you throw up a HTML window with almost zero overhead (the OS used the same libraries) and javascript could get data easily from another process via COM etc.
Now like 25 years later, apparently our choices are shipping bespoke copies of Chrome and Node, OR making shit work on an emulated 1981 DEC terminal. Lack of vision is exactly right.
I think for the time being, there's no way to get around writing native UIs to get a native experience. Any sufficiently high level APIs will have to give up something. TUIs for me fill that niche because across any POSIX-compatible interface they will generally work the same, and modern high level languages make cross-compiling to terminals a breeze. Now to write a native UI across Windows, MacOS, Wayland and X11, that's a different story.
I’m happy to give up a lot; I’m not tied to fully-native-looking UIs for the types of things I’m talking about. Totally get that lowest common denominators will feel native nowhere. I just think it’s possible to do a lot better than the current state of TUIs.
We do. We are only stubborn. Cross platform and low-footprint:
> TUIs are typically small, low footprint applications
That ship has sailed. These days, TUIs are often Node.js / React monstrosities. Claude Code is a case in point.
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:
I’m not just talking about screen readers, though they are important. I mean “accessible” more generally. Yes you could build a specific UI for each kind of user, but that seems far less likely to cover as many uses as building one UI that is structured, programmatically navigable, etc.
>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.
Funnily, Emacs is getting closer to what I’m after (it’s my main editor).
> That's not necessarily bad. Not everything has to be open ended.
I think it is necessarily bad and everything should be open ended. Bad in the sense of low quality, but if we’re talking about critical accessibility (someone is unable to use your application at all), morally bad too.
How many developers are using VSCode? How does that number compare with Emacs/Vim?
In many ways, GUI was developed as the natural evolution of TUI. X server, with its client-server architecture, is meant to allow you to interact with remote sessions via "casted" GUI rather than a terminal.
Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.
TUI just got the nostalgia "coolness".
>How many developers are using VSCode? How does that number compare with Emacs/Vim?
How many people eat microwave meals? How many eat gourmet Michelin star dishes?
I don't care "how many use VSCode". My argument Emacs/Vim have great, well loved TUIs. And they are used by a huge number of the most respected coders in the industry. Whether a million React jockeys use VSCode doesn't negate this.
>Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason.
Yes, it sells to the masses. Countless food industry scientists aspend many man-hours to develop detrimental ultra-processed crap for a reason too.
The analogy mostly makes a point for snobbishness, but otherwise doesn’t really work. Most people would rather eat meals prepped by a Michelin star cook, but they can only afford microwave meals - whereas EMacs/Vim and VSCode are equally accessible to anyone.
>Most people would rather eat meals prepped by a Michelin star cook,
You'd be surprised. Most people can't eat anything adventurous or out of the junk-food category with some comfort food staples thrown in.
I love emacs but would never compare that with a Michelin meal! On the contrary, emacs is the DIY option that lets you experiment with whatever ingredients you please without judging your choices!
I think their point was about “most popular” not necessarily meaning “better”. I don’t think they meant anything more by it
> My argument Emacs/Vim have great, well loved TUIs.
They... are not great. They provide the absolute bare minimum of an UI.
An UI, even a terminal one, is more than a couple of boxes with text in them. Unfortunately, actual great TUIs more or less died in the 1990s. You can google Turbo Vision for examples.
The vast majority of people don't use the Emacs TUI and it is explicitly recommended to use the GUI.
> How many developers are using VSCode? How does that number compare with Emacs/Vim?
Perhaps I'm in some sort of "TUI bubble", but I'd bet good money that Emacs/Vim users outnumber VSCode users by an order of magnitude. But maybe I'm just surrounded by *nix devs.
I'll take that bet
No need to guess, the SO survey is probably still representative of the state of development environments:
https://survey.stackoverflow.co/2025/technology#1-dev-id-es
Note that respondents may use multiple tools, but around 76% answered VSCode, whereas 24% answered Vim.
So, I’d wager you’re indeed in a *nix bubble.
The SO survey was skewed to begin with, and by 2025 it covers a much reduced fraction of past users. See:
https://meta.stackoverflow.com/q/437921/1593077
Not that your conclusion is necessarily wrong of course.
That is so different than I expected. Thank you for the link.
It's more indicative of the state of SO users.
Care to bet even those 24% vim devs code circles around the VSCode ones?
> but I'd bet good money that Emacs/Vim users outnumber VSCode users by an order of magnitude
No, no they don't. Enterprise and gaming alone would easily invalidate your bet.
I agree except about the TUI coolness factor. There really is a lot that’s appealing about TUIs, I agree on that with the other commenters here. I want a better synthesis than what we have.
Buddy, I am here to inform you that you are projecting.
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.
I don't quite agree with this. Feature discovery is much easier in GUI when most commonly used features are either in the first layer of menu or in standard hotkeys. In the worst case, you would do a search in GUIs that provide them. In CLI / TUI, no such function is present and you would basically have to man and scroll through all possible commands to find it, though I guess grep helps.
You accept search in GUI, but don't in man pages? Scrolling through actions in a tree-like menu structure is ok, but through a tree-like structure in the --help output is not? Feels inconsistent.
The whole benefit of text-based interface is that search, filter and transformation is always available and completely independent of the running program.
I can see the visual discoverability aspect for GUIs, but for the visual layout GUIs and TUIs are on par, the difference is rather in the rendering mechanism: pixel vs. character-based.
>The whole benefit of text-based interface is that search, filter and transformation is always available
That's the point about TUIs, they remove this benefit. You can't (practically) grep the output of btop or vim or whatever.
I agree about the constraints. My ideal solution would also impose harsh constraints, but would also add just enough structure. I’m also frustrated by each app reinventing the same thing slightly differently.
> because menus and rows of buttons are not cool anymore.
They are, which is why most desktop applications use them.
(And please help remind the GNOME people of this fact.)
Zed has a menu tho?
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've use Claude to make myself a number of little tools and weird apps that only I would want lately. They need to be cross-platform between Linux and Mac and sometimes Windows. The best approaches I've found are Tauri (+Svelte for making layout easier) for lightweight GUIs but for anything more complex I prefer a TUI. The Ratatui framework works very well. A TUI feels like a "real" app as opposed to a glorified webpage. For actually serious software I'd want a native GUI on each platform.
There are so many options for what you describe. E.g. the whole point of Tcl/Tk is to allow easy creation of small little tools and apps. And you can use Tk with Python as well.
> A TUI feels like a "real" app as opposed to a glorified webpage.
Huh? "Feels"? Plenty of Electron/Tauri apps feel perfectly normal. Like I've been saying, the TUI craze is just a fad.
A TUI app feels like a native terminal app like I have used for my entire computing life, in DOS and then Linux. Electron apps feel like web apps no matter how good they are. I stopped using 1Password when it became an Electron app and became super janky. Discord, Slack, VS Code, the Signal desktop app, all suck UI-wise compared to actual native Mac apps, which even with Liquid Ass, are still better than using web technology for desktop apps. I know that lowest common denominator cross platform apps make economic sense to develop, whatever. They still suck to use.
Again this word "feels". Is it not just nostalgia?
No. Good TUI apps are predictable and fast, like good native GUI apps. They follow set patterns. Familiarity and following standard conventions is not just "nostalgia" -- maybe a little is in there -- but it makes apps more usable. And, for cross-platform apps, it's a cross-platform standard. I'd rather have a TUI app following TUI conventions than a cross-platform app that is just a freeform mish-mash. Like, this week I've been making a TUI replacement for Plexamp which has great features but its Mac app is just like a scrolling webpage. If I am going to have a GUI app that is more than a tiny toy or utility I want it to follow each platform's native conventions and use its native GUI components or to not even bother. I will grant that Electron has made strides in terms of properly integrating into each host OS (using the full Mac menu bar, the correct keyboard shortcuts, accessibility features and so on) so the situation is not as bad as it once was. And also, plenty of people use and have used terminal editors and other tools by choice, for years, and not just because they are connecting to remote servers. A keyboard-first interface can be quite fast and they are more natural in TUIs.
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.
Yeah, I sympathise. This is another angle on the sorry state of affairs we find ourselves in.
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.
No. The browser structures the page in both a DOM tree and an accessibility tree.
> You’re forced to use it exactly the way it was designed and no different
So ... Like all Apple products?
Not even close. Apple UIs - despite recent graphical howlers - have excellent accessibility APIs and are regularly praised by people that track such things. I’ve recently been building a macOS app and the UI testing is also based off it. There are apps that allow full keyboard navigation using it. I do agree that the window management side is much less customisable, though, and that does frustrate me.
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
Did you reply to the correct post? Can’t see how it follows from mine.
Building a TUI was easy before, especially with the great toolsets for their respective languages BubbleTea / Textualize / Ratatui. And thanks to those frameworks, LLMs can manifest useful tools.
Similar to WebApps, it's only since the November'25 renaissance that I felt I could use them to create TUIs. Once I had that revelation, I started going into my backlog and using it.
I maintain a TUI Charting library, NTCharts. In January, I fixed a bug - totally obvious once identified - that I personally failed to find earlier. But the test harness, prompting, and Gemini got it done [1]. Gemini's spatial understanding was critical in completing the task.
I've been vibe-crafting a local LLM conversation viewing tool called thinkt. After scraping ~/.claude and making a data model, this is the point in PROMPTS.md where I start creating the TUI using BubbleTea. [2].
[1] https://github.com/NimbleMarkets/ntcharts/issues/7#issuecomm...
[2] https://github.com/wethinkt/go-thinkt/blob/main/PROMPTS.md#2...
As LLMs consume all our compute resources and drive up prices for the compute hardware on which we run applications, the silver lining is that LLMs are helpful in implementing tooling without a heavy stack so it will run quickly on a lower-spec computer.
I've achieved 3 and 4 orders of magnitude CPU performance boosts and 50% RAM reductions using C in places I wouldn't normally and by selecting/designing efficient data structures. TUIs are a good example of this trend. For internal engineering, to be able to present the information we need while bypassing the millions of SLoC in the webstack is more efficient in almost every regard.
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.
A very important thing about constraints is that they also liberate. TUIs automatically work over ssh, can be suspended with ctrl-z and such, and the keyboard focus has resulted in helpful conventions like ctrl-R that tend to not be as prominent in GUIs.
What does ctrl-R do?
History search, like in shells. My most used TUI shortcut!
>would be still more performant than TUI's, which are bound by the limitations of emulating terminals.
That's what makes them great. As opposed to modern "minimal" waste of space UIs or the Electron crappage.
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.
When global supply chains are disrupted again, energy and/or compute costs will skyrocket, meaning your org may be forced to defer hardware upgrades and LLMs may no longer be cost effective (as over-leveraged AI companies attempt to recover their investment with less hardware than they'd planned.) Once this happens, it may be too late to draw on LLMs to quickly refactor your code.
If your business requirements are stable and you have a good test suite, you're living in a golden age for leveraging your current access to LLMs to reduce your future operational costs.
In the past week I made 4 different tasks that were going to make my m4brun at full tilt for a week optimized down to 20 minutes with just a few prompts. So more like an hour to pay off not decades. average claude invocation is .3 wh. m4 usez 40-60 watts, so 24x7x40 >> .3 * 10
Would it be that many? Asked AI to do some rough calculation, and it spit that:
Making 50 SOTA AI requests per day ≈ running a 10W LED bulb for about 2.5 hours per day
Given I usually have 2-3 lights on all day in the house, that's like 1500 LLM requests per day (which sounds quite more than I do).
So even a month worth of requests for building some software doesn't sound that much. Having a local beefy traditional build server compling or running tests for 4 hours a day would be like ~7,600 requests/day
> Making 50 SOTA AI requests per day ≈ running a 10W LED bulb for about 2.5 hours per day
This seems remarkably far from what we know. I mean, just to run the data centre aircon will be an order of magnitude greater than that.
Air conditioning for a whole data center services a whole data center, not one machine running a task for 1 min
Yes... But the machines in those data centres don't get there without the companies who put them there. You get no tasks for no minutes, without the infrastructure, and so the infrastructure does actually have to be part of the environmental impact survey.
Is that true? Because that's indeed FAR less than I thought. That would definitely make me worry a lot less about energy consumption (not that I would go and consume more but not feeling guilty I guess).
A H100 uses about 1000W including networking gear and can generate 80-150 t/s for a 70B model like llama.
So back of the napkin, for a decently sized 1000 token response you’re talking about 8s/3600s*1000 = 2wh which even in California is about $0.001 of electricity.
With batched parallel requests this scales down further. Even a MacBook M3 on battery power can do inference quickly and efficiently. Large scale training is the power hog.
I’m not really worried about energy consumption. We have more energy falling out of the sky than we could ever need. I’m much more interested in saving human time so we can focus on bigger problems, like using that free energy instead of killing ourselves extracting and burning limited resources.
Especially considering that suddenly everyone and their mother create their own software with LLMs instead of using almost-perfect-but-slighty-non-ideal software others written before.
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 think mc (Midnight Commander) is still one of the best TUIs available - it's very close in capability to the GUI versions (like Double Commander) and it has the benefits of tuis - like that you can run it on a remote system. It looks outdated, but I'm actually now working on a new skin that will hopefully be included in the next release of mc.
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 genuinely don't understand the TUI obsession for LLM applications.
Go watch copilot drive VS2026 if you've never seen it in action. There is no way you are going to be able to communicate this same amount of information via plain text in the same amount of time. I can catch a lot of bad stuff mid-flight because I can actually multitask my UI and click into diffs as files are edited in real time.
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.
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.
Actual hackers will use AWK and anything else... over Acme under 9front which is pretty much graphical, and current Emacs users will use a graphical setup with tons of keybindings, commands and Elisp functions. The best of both worlds. You have both the scriptability, keyboard shortcuts and mouse for selection and quick pointng.
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.
I don't disagree. However, the TUI seems to have become the final destination for some major AI vendors. This doesn't look like a stepping stone to me.
I have been wondering where this trend started as well. It's geared towards vibe coders who don't need to see a lot of info.
How fast does it need to be? We're talking about LLMs that run in the cloud here.
Fast as in time-to-market
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.
I don't see any real advantage of TUIs over web forms or GUIs for the same thing.
I do like CLIs though, especially the ones that are properly capable of working in pipelines. Composing a pipeline of simple command-line utilities to achieve exactly what you want is very powerful.
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.)
> 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.
Did you try some tiling window managers and decided you did not like that?
I prefer most apps to not tile. Tiling window managers might still work with config.
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.
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)
> 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
And that helps? I tried that a while ago and it very often said this is not a good way of doing something even though it was objectively the best way of doing something. I removed it after a while because it was too random.
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).
They can, but don't always. I've used some where you have to smash the TAB key 50 times go move linearly through all the fields and controls. If there are well-implemented navigation keys, yes they it can be very efficient.
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.
Gemini built a nice TUI for me for a DHT scraper project I was coding:
https://imgur.com/a/u3KHbDT
It was like two-shot, cos the first version had some issues with CJK chars.
I was impressed as it would have taken me a bunch of screwing around on lining up all the data etc when I wanted to concentrate on the scraping algorithm, not the pretty bits.
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.)
I love Claude Code, but how they made the TUI is just plain stupid. Not how it looks, but you know, the React part.
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?
It's just architected poorly. The job of putting text on a screen fast has been solved for 50 years.
If the render is already made in JavaScript it makes sense to reuse react as the reconciliation engine instead of building one from scratch.
What is a "reconciliation engine" and why does a TUI need one?
Just like in GUI, in a TUI you need some mechanism to make the rendering output (the characters) match the internal state of the application.
E.g., the user hit ESC -> internal state is CANCELED/WAIT FOR USER -> internal GUI representation now includes a prompt that asks the user to tell Claude what to do differently -> rendering output actually shows said prompt.
It solves the problem of if the UI changes, what characters on the terminal do we need to update to show the right thing to the user.
No, no it makes exactly zero sense to have a "reconciliation engine" or React in a TUI. There's nothing to reconcile. You can just output a stream of characters as fast as they appear.
That’s not a TUI, that’s a CLI.
Any stateful UI needs a state management backend and a rendering frontend, React isn’t a bad choice for the former.
React is not, and has never been a "state management backend".
There are about a million other ways of doing state management than retrofitting it into both React and TUI.
Parent comment talks about using React for reconsilliation which is React-speak for "we take a diff between current state of UI and new state of UI, and apply that diff". Which is entirely unnecessary not just for TUIs, but for the vast majority of GUIs in general, especially for non-DOM-based ones.
As an example, in Claude Code this insanity leads to them spending 16ms "creating a scene" and rendering a couple of hundred of characters on screen: https://x.com/trq212/status/2014051501786931427
That post doesn't say that it takes 16ms to create a scene and have the terminal rasterize and try and present it. That's just the budget they have. It is the upper bound they have to work with.
For example Claude Code could emit a strange symbol and if the terminal has to go and load a font from disk to be able to rasterize something that can eat into the budget and prevent the terminal from having a smooth frame rate by causing a frame drop.
> That post doesn't say that it takes 16ms to create a scene and have the terminal rasterize and try and present it.
So they literally take 16ms to rasterize just a few hundred characters on screen. Of those, 11ms are spent in "React scene graph", and they have 5ms to do the extremely complex task of rendering a few characters.
16ms is an eternity. A game engine renders thiusands if complex 3D objects in less time. You can output text to terminal at hundreds of frames per second in Javascript: https://youtu.be/LvW1HTSLPEk?si=G9gIwNknqXEWAM96
> and if the terminal has to go and load a font from disk to be able to rasterize something that can eat into the budget
Into which budget? They spend 11ms "laying out a scene" for a few hundred characters. "Reading something from disk" to render something is a rare event. And that's before we start questioning assumptions about read speeds [1], whether something needs to be rendered in a TUI at 60fps etc.
[1] Modern SSDs can probably load half of their contents into cache before you even begin to see the impact on frames. Unless it's a Microsoft terminal for which they claim they need a PhD to make it fast.
More on disk read speed: https://planetscale.com/blog/io-devices-and-latency
--- start quote ---
A typical random read [on a HDD] can be performed in 1-3 milliseconds.
A random read on an SSD varies by model, but can execute as fast as 16μs (μs = microsecond, which is one millionth of a second).
--- end quote ---
If you drop frames in a TUI on a HDD/SDD read for a font file (10-20 KB), you're likely completely incompetent.
>So they literally take 16ms to rasterize just a few hundred characters on screen
Did you measure this yourself? Where is this number coming from? I am talking about a budget. Even if it takes 1ms total as long as that is under 16 ms that is fine.
> Where is this number coming from?
They literally complain about that in yhe tweet I linked. That they spend 11 ms in React and only have 5ms to do the impossibly hard task of outputting a few characters on screen.
> Even if it takes 1ms total as long as that is under 16 ms that is fine.
How is it fine when you can re-render the entire terminal in microseconds (I also linked a demo for that, too), and they take 11 milliseconds just "constructing React scene"?
It doesn't matter if they take 12ms to render or 16ms. You're completely missing the point.
Never said what CC is doing is right. Using React for knowing what to render is good enough for state management for me, that they can’t or won’t figure out how to emit less escape sequences than they need to (which is a solved problem for 40 or 50 years now in windowing UIs) is a different thing.
For the record I can’t stand CC flickering and general slowness and ditched Claude subscription entirely.
> Using React for knowing what to render is good enough for state management for me
In TUIs you can re-render the entire screen at hundreds of frames per second. Has nothing to do with state management. Doesn't need React to "figure out what to render".
Again, React is not a state management library. And it's not really applicable to non-DOM rendering approaches.
Some of my personal favourites TUI are all over GitHub and there are lots of them to have a look at can be found here:
https://github.com/rothgar/awesome-tuis
https://terminaltrove.com/explore/
Building for Charm, ratatui and many others is really getting much easier than before thanks to AI.
Indeed. Over a few days of iterations I had this TUI built for fast full-text search of Claude Code or Codex sessions using Ratatui (and Tantivy for the full-text search index). I would never have dreamed of this pre coding agents.
https://pchalasani.github.io/claude-code-tools/tools/aichat/...
Building TUIs was already super easy in 1990 with Turbo Vision and Clipper on MS-DOS, with compiled languages (TP, xBase), using super fast build times on systems running at 10 Mhz, within 640 KB.
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.
The thing with TUIs is that, using mobile native virtual keyboards, it's apparently quite impossible to make them behave in a sane way in browsers!
I think the only reasonable option seems to be reimplementing one yourself, which is massively stupid.
Mobile is not for TUI
More specifically it's an interface designed for a physical keyboard. Or even more specifically it's designed for precise and easy human text input.
especially where you typically type with all fingers instead of just your thumbs
Sure it is. I, and millions of others, use it all the time with for example Termux.
My Ratatui test app (Conway's Life) runs great in Termux. :)
Termux is seriously amazing (with its quirks, of course)!
Have you tried porting your test app to a web page? I'd really like to have a good TUI experience on the web.
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).
I also use Termux daily!
It's really a superb tool.
I only wish we could have that same experience without requiring a native app.
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.
"Building X is easy now"... it was never hard if you had the patience to read docs.
We should be saying "Building X is faster now" instead. But I guess that doesn't induce god complex that effectively.
Hi everyone, I enjoyed building this TUI for myself and wanted to write down how I did it. I appreciate all the thoughts and feedback! The web app is our main investment, but I think there's a slice of developers who really like to interact with TUIs, so I'm going to keep working on it.
For the demo at https://tui.hatchet.run, to answer some messages asking about it: I built this with the fantastic ghostty-web project (https://github.com/coder/ghostty-web). It's been a while since I've used WASM for anything and this made it really easy. I deployed the demo across six Fly.io regions (hooray stateless apps) to try to minimize the impact of keystroke latency, but I imagine it's still felt by quite a few people.
I never turn down a chance to plug my favourite TUI - jjui, for controlling jj vcs. Life changing combination (and jjui is built with Charm)
https://github.com/idursun/jjui/
> Notably this was the first time I felt that using Claude Code for something non-arbitrary was significantly faster than doing it myself
Well, it is like code completion on a higher level.
I still don't like this approach. Besides, who is going to maintain that code? Such code will probably forever be required to be maitnained via Claude. So no humans involved. Just autogenerated stuff. I dislike this idea a lot.
Humans are slower, ok, but they built excellent software before Claude. What is coming next? Claude Linux-like Kernel? Top500 supercomputers will run it?
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.
Turbo C++ was peak TUI. Even on hardware thousands of times slower than today it had that instantaneous wired-to-the-machine feeling that I rarely experience today.
I too enjoy the charm TUI libraries, and have been using them to build a settlers of Catan game[0]. And some features are really cool, like different colors depending on dark/light theme.
They have a bunch of functions that concatenate strings, which may not be very efficient compared to using string.builders, but I haven't yet had performance problems.
However I haven't had such a great experience with AI, IMO they're bad at ASCII art.
[0]: https://sr.ht/~vicho/el_poblador/
Hey! This looks great, and I appreciate the effort! But just opening the page at https://tui.hatchet.run/ causes my (admittedly old Intel i7 9700K) to spin up its fans and consume >30% of the CPU without me even doing anything. I don't think a TUI should do that.
I was also intrigued by it being a lot of Go dependencies as I have developed a bit of a fancy for this language recently.
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.
I knew this would be ANOTHER ai glazing post before even clicking. I think we must specify if a post is about AI in titles. Another "I built X" with AI really brings nothing to the table, and I've seen a few users agree with me on this.
https://news.ycombinator.com/item?id=46580844
Here's a similar situation, a submission called "webdev is fun again", and what you find inside is just gushing about how good AI is. Genuinely what value does it bring? I think this phenomenon is literally "clickbaiting" but on hackernews
Other users from here seem to see the same thing that I do:
https://news.ycombinator.com/item?id=47008412
https://news.ycombinator.com/item?id=47010624
Big reason why TUIs were popular in the first place is because they are so much simpler to build. Compare ncurses to GTK/Qt, they are completely different leagues. One of my pet ideas is to build a ncurses compatible/style library that skips terminal layer and instead renders directly to Wayland, kinda getting the simplicity of ncurses without dragging all the legacy junk with it.
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.
> Yet ironically getting Claude Code to run at 60fps is way way harder in a TUI?
That's what happens when you vibe code your app.
It's just their tech debt. They chose to use react.js in the terminal via ink, and essentially footgun their way through each update.
Building TUIs might be easy now but building good user experience on a TUI is feels harder than ever has been to me. The modern libraries make a lot of things easy but we are currently pushing terminals far beyond what they were designed for.
Claude Code et.al. are good examples of that. Diffs, user approval flows, non-linear flows in general and a ton of text buffered are all elements that we know really well how to handle in web interfaces but are challenging for the terminal.
What‘s the TUI equivalent for mobile apps? Big UI elements and text, iOS 1-6 style, rendered without bitmap graphics?
I.e. something that is lightweight, lightning fast, great to use with just a thumb or so and looks a bit boring and dated, yet also inviting?
TUIs are great fun and Claude can make beautiful ones with a little ratatui action super fast. However, the downside of these are that you can't use them with Claude Code so while I have a few I prefer to also have a prompt-response CLI function since that's better for lots of things.
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.
Yeah, this is my main way of using Claude Code for anything complex – a REPL or bash window in tmux, and with Claude running commands there. That lets me easily browse through anything that's happened in a UI I'm used to, or manually intervene if needed.
That's pretty nice! It's just the context window problem, yes, but the tmux tip is pretty good nonetheless.
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.
Building an article is easy now.
Hah.
The cursor CLI was a great springboard for me to make my own frontend to prompt from, I would never use it though god, I implemented git, difs, and chat histories, so i can use it easily from my phone with tailscale. It picks up on my rules and can grep my project, so easy. https://imgur.com/a/HZOEvr7
I haven’t done much with Claude code yet but I’ve watched some rather recent videos of other people leverage it to get work done and I couldn’t help thinking, are we going to end up with a similar UI but with fully deterministic “agents” at the end of this hype cycle.
All of the skills I saw demonstrated were deterministic. So does this end in a Functional Core, Imperative Shell scenario that looks like a Terraform Plan and a search engine-style natural language processor out front?
Dagger has a really nice TUI built on Charm. It reads OTEL to create an interactive tree for your builds and containers. If you have cloud setup, it will also push that all to a webapp interface where you can share and navigate in perpetuity. This works for both CI and local runs, super cool for sharing links to failed builds during dev, even while the dev's local build is still running
https://www.youtube.com/watch?v=EPEGTfaFnpA
Looks great. Curious why not choose Rust and do extension of https://ratatui.rs/?
Yeah, whenever I hear "Building a TUI is easy now" I imagine someone just discovered ratatui.
There are also other frameworks that make it easy to create TUI eg Textual (in Python) https://textual.textualize.io/
If it was so easy Anthropic wouldn't have messed up CC for so long. The author takes for granted the availability of good off-the-shelf TUI libraries for his chosen language.
Do we want tuis?
I can’t stand Gemmin-CLI. That tui gets in the way constantly
I’m mixed in jj’s tui. It’s better than no ui tho
Mostly tho I’m curious when I’d want a tui. Most of the time in a terminal I don’t want one
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.
VS Code with the Vim extension is largely mouseless
I use the TUI from a terminal tab in VS Code, my agent works with that and the custom extension with a webapp based interface, seamlessly and concurrently
GUIs, TUIs, and PR/kanban all make sense in different situations. We'll all use at least two of them on regular basis for coding agents.
TUIs make way less sense for your average user
> VS Code with the Vim extension is largely mouseless
It's also easily mouseless without any Vim or like extension. I never mouse in it, having given intuitive-to-me keychords to all the various moves I need to make beyond the standard stuff.
true, I would never have moved over if I had to give up my vim bindings and modes
I just want a stream, not a TUI. If you can't | it it's not real
There’s no reason why you can’t have both.
Well behaved CLI tools have for years already been changing their UX depending on whether STDOUT is a TTY or a pipe.
Have you tried jjui? It’s pretty nice
Claude Code has done a good job of building a tui MUD client (I couldn’t find one I liked), and then building a GUI version using Tauri where all the config is shared, so you can run it as either a GUI (on any platform) or TUI. Happy with it so far, and I personally use both TUI mode or GUI mode (with floating panes) depending on what I’m doing.
I was working on a fairly niche thing, a library of crossplane compositions written in KCL and thought it would be nice to have a TUI so i could browse through them and see the rendered yaml as claude was working on it. I asked claude code to write it with python and textual and it one shotted it in about two minutes including a test suite.
With Claude, I built a TUI for managing QEMU/KVM VMs (Rust with ratatui.) Solves a lot of problems I had with virt-manager, so I made it a FOSSS project. https://www.vm-curator.org.
There are plenty of great tools available these days. Bubbletea would be my tool of choice, I think:
https://github.com/charmbracelet/bubbletea
Charm is what the post submission is using
it's always been easy with ansi... Everyone just thinks it's hard because there's no React for TUI's until recently. '\x1b[' is all you need.
It was good enough for ncurses, it's good enough today.
They are! I (well, Claude) built nitpick as a TUI HN client, and it was surprisingly easy to do.
https://github.com/fragmede/nitpick
Charm looks good. What is the TUI library of choice for python these days?
https://www.textualize.io/
Using librairies, building TUI was easy before AI too.
The problem with TUI's, that we have all Stockholm syndrom'd ourselves, is that I can't use the mouse cursor to click to the position on the screen and edit the command line.
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
It is possible. Terminals have supported mouse interactions for a long time.
possible isn't the same as supported and working. A non-terminal hunt-and-peck typer sits down and is presented with a terminal, what's the second that happens when they're typing? they make a mistake and try to click on the word they misspelled, and it doesn't work.
That’s a very specific gripe to make. So specific that you have to acknowledge it’s not going to be a deal breaker for everyone. Which makes me wonder why you’d use the “Stockholm Syndrome” argument — assuming you used it in good faith and not just because you wanted to sound edgy (or some approximate synonym of)
It's a thing that confuses every single person the first time they touch a terminal! Could do without the diction-based ad hominem.
> It's a thing that confuses every single person the first time they touch a terminal!
I get that. But it doesn’t mean those that prefer the terminal have Stockholm Syndrome.
The terminal is a UI optimised for keyboard entry. So of course mouse input to move the caret wouldn’t be something that is prioritised to support.
Again, that’s not Stockholm Syndrome; it’s just a different workflow.
> Could do without the diction-based ad hominem.
You’re the one making ad hominem attacks by saying CLI users suffer from “Stockholm Syndrome”. That was your comment not mine.
I said I was willing to take your comment in good faith. Which isn’t a personal attack.
I’m really not interesting in meta arguments nor using intentionally antagonistic language. And if you continue to communicate this way then I will just ignore you.
A terminal emulator in a GUI environment such as Linux is expected to play nice with the GUI and support mouse-based select, copy and paste, as well as being a terminal emulator, and this means that the terminal itself is consuming mouse events to support text selection.
If you wanted to write a shell that has mouse support you could certainly do so, and this would be based on sending escape codes to the terminal to tell it to return mouse events as input rather than let the terminal consume them itself. The shell could then itself support the clipboard if it wanted to, as well as support mouse editing.
I just googled it, and apparently "fish shell" does exactly this, but your hypothetical user is more likely to stumble upon a bash shell which is letting the terminal emulator consume the mouse events and support copy and paste.
What TUIs are you referring to? Mouse is supported and working on just about every TUI framework.
bash readline
Readline is one of the oldest libraries available on modern systems.
So old that Charm, the framework featured in this article, is written in a programming language that was decades away from conception back when readline was first released.
Comparing modern TUIs to readline is like comparing an analogue rotary phone to a smartphone.
Readline is also no longer the default experience for your average new user since macOS switched to Zsh many years ago and Microsoft will push Powershell over WSL in the row documentation.
I do get the point you’re trying to make. But it’s a pretty weak argument give the age of your examples.
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.
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.
Doesn’t work on an iPad. It’s not that hard to fix, but shows that the fundamentals of input handling and accessibility aren’t there.
TUI may look good on the surface, but I’d really appreciate to see a good descriptive logs instead of a fancy progress bar
> The Hatchet TUI is not well supported on mobile devices.
Isn't everyone else remoting into a Claude instance on their phones?
Primary driver for me (finally) learning tmux.
> most importantly, they live inline to your code, preventing constant tab switching
No idea what this means.
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.
Were TUIs hard before?
TUI: Terminal User Interface
"Creating garbage is easy now."
It runs poorly, loses keystrokes, and easily gets bogged down with too much terminal input.
I don't want candy coated monospace ASCII graphics. I want something fast and functional. The graphics are _entirely_ secondary. You've missed the point of what a TUI is.
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.
It’s not easy to build a good tui though. Like fe compare Claude code and opencode. Opencode is an atrocious approximation of a window system as a tui.
[dead]
I think pi-mono (https://github.com/badlogic/pi-mono) is pretty close. The extensibility is wonderful and a much better fit for how I work compared to Claude Code.
[dead]