Deploy More Resilient Apps. Hatchet is a platform for building distributed web apps that solves scaling problems like concurrency, fairness, and rate limiting.
When I first booted up Claude Code in May 2025, I thought: huh, this is cute. A terminal-based coding agent...they must be pandering to developers.
Within the first 30 minutes, I was convinced: this was going to be huge. So huge that we at Hatchet discussed whether we should build a new product line around terminal-based coding agents.
Ultimately, we decided against it, but that first experience with Claude Code stuck with me. It seems so simple and obvious in hindsight that a terminal-based agent would have a incredibly fast adoption curve among developers.
Perhaps you have a similar feeling that the tool you're working on should have a TUI. Perhaps you've always wanted to build a TUI yourself. Or perhaps you just like saying too-ee.
I say: go for it. It's much easier than I was expecting, using a few neat tricks with Claude Code. This is coming from a skeptic. We had previously attempted an aggressive, agent-first refactor of our frontend which was built in a week, bug-bashed for five, then abandoned.
In comparison, this TUI was mostly driven by Claude Code, but was built and shipped in a few days. You can check it out a live demo here:
For all you budding TUI developers, I wanted to write out some of the decisions that made this significantly easier than similar projects of mine: a “happy path” to building a successful TUI application.
Why build a TUI?
I've always wanted a TUI for Hatchet. Something like k9s, but for tasks and workflow runs. I wasn't sure anyone else would find it useful, and we didn't even really announce it to our community, but within a few days we got some very positive, unsolicited feedback from our users. For example:
Guys great work on the Hatchet CLI (especially the TUI!) It feels so [much more] performant than the UI.
I love this comment, because it gets at the heart of why I love TUIs - they just feel easier to use, even though it uses the exact same API as the UI. They're also the opposite of how web applications have been trending the past few years: TUIs are text-first, information-dense, and most importantly, they live inline to your code, preventing constant tab switching. And since our users are primarily developing Hatchet tasks and durable workflows in their IDE, we wanted to provide an experience where workflows could be visualized and run from a terminal, instead of constantly switching between your code and your browser.
The stack
Let's get into the details. Every frontend application starts with a stack: A typical one these days might be React, react-query, Tailwind, ShadCN, and some additional Tanstack libraries.
There's an equivalent of these libraries for TUI development — and they're all maintained by the same company! I'm referring to the Charm stack: if you're unfamiliar, the team at Charm has been building out a set of TUI libraries which are incredibly delightful to use. I primarily used Bubble Tea, Lip Gloss, and Huh. Don't let the cutesy nature of these libraries fool you — they're incredibly well-documented and have tons of examples.
And while I found it slightly more difficult to build anything custom outside of Bubble Tea and Bubbles, it's certainly easier than building a React-based rendering engine like the one that Claude Code uses internally.
One of my favorite bits was the ease at which I could apply a style to any TUI element in a way that felt cohesive using Lip Gloss and Huh themes. I then reused this style throughout the Hatchet CLI, instead of just with the TUI. For example, most commands in the Hatchet CLI are interactive by default, with forms that use the Lip Gloss theme:
Testing
The most important piece of testing was Claude Code: it turns out that a terminal-based coding agent is exceptionally good at driving other terminal-based tools. This means that the development process looks something like: build a component or view, compile your TUI, and have Claude Code drive the first pass of testing for it.
I had seen a comment on Hacker News about using Claude Code to drive a tmux session which uses tmux capture-pane to store rendered views and test to make sure they seem correct. This was remarkably effective at driving a first pass of testing, and also ensuring that the proliferation of views continued to render properly (even the Hatchet TUI, which is a relatively simple set of 4 primary views, but contains at least 6 other modals which replace the viewport). Here's what Claude Code "sees" when driving a tmux session:
Historically, my biggest frustration with coding agents for features that involve e2e or frontend testing is the feedback loop. Not in this case: LLMs are built to iterate in ASCII-based environments. After Claude Code drove the first pass of testing, I then manually tested each view along with writing unit tests for anything critical. After a few iterations of this, the TUI ended up in a surprisingly stable place. Iterations felt convergent instead of divergent.
Playing on easy mode
Claude Code is much more effective when using a reference implementation. Our reference implementation is our existing frontend. So most of my instructions for Claude Code referenced an existing and very specific set of frontend views, components or hooks. We don't do anything too crazy in our frontend, and we try to keep our components and views as simple as possible, with business logic and API calls offloaded to various React hooks. This gave Claude Code a very clear boundary of separation to build out each view with business logic first, views second.
We also benefited massively from using an OpenAPI spec to generate our server interfaces and REST API clients, which gave Claude Code a simple reference and auto-generated client to interface with our API.
I initially suspected that the hardest component to build would be the DAG-based renderer. For context, Hatchet is unique in the space of orchestrators in that it supports single tasks, durable execution via durable tasks, and DAG-based execution. Rendering DAGs is a tough problem abstracted for us in our frontend by the fantastic React Flow which handles a bunch of the complexity around rendering DAGs and graphs properly:
It didn't seem tractable to transpile the React Flow internals to the TUI, so I tried a different approach. I went through a few failed iterations of prompting Claude Code to build this before I decided to dig into it. I searched online for existing implementations of ASCII-based graph renderers and stumbled upon https://github.com/AlexanderGrooff/mermaid-ascii. I cloned this repository, pointed Claude Code at it, wrote several paragraphs of a prompt, and got it to render a working DAG renderer within the first try.
It's not quite pixel-perfect, but it's getting there.
The result
All told, this took about 2 days of effort. Notably this was the first time I felt that using Claude Code for something non-arbitrary was significantly faster than doing it myself. The aforementioned frontend refactor fiasco bore all the hallmarks of agentic antipattern: incredibly fast to get something extremely promising working, then losing the plot in a wave of complexity and bugs caused by subtle bugs upon subtle bugs. A house of cards. We reverted the frontend changes after a difficult pre-turned-postmortem.
This was a big shift for me: releasing a major feature, which has been working reliably for me with aggressive usage over the past few weeks, driven by a coding agent. While we're not going full yolo mode with our agents any time soon, we're gradually using them more and more, particularly for less-critical paths (if your TUI crashes, it hopefully doesn't bring down your production. This is not true of your queueing system).
Perhaps the lessons are a little boring and intuitive to more experienced engineers: building an environment with a tight feedback loop, modular design, proper specifications, continuous testing and deployment, yada yada. But I finally feel like I'm in the loop.
Linking the live demo again here, would love to hear your feedback!
Read the original article
Comments
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!
By zelphirkalt 2026-02-141:401 reply While you are at it, it would be good, if the post was readable at all, without having to run JS on the page.
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.
By syene 2026-02-154:39 It must have sent it differently if the browser reports it can’t do JavaScript.
By zelphirkalt 2026-02-1412:281 reply 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.
By syene 2026-02-154:42 I don’t think EWW has ever made my Emacs crash. I wanna say I’ve been using it regularly since Emacs 27.
By huflungdung 2026-02-141:36 [dead]
> to Commodore 64 level
That’s unfair to C64 which can smooth scroll very well.
By weinzierl 2026-02-1413:04 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.
By npsomaratna 2026-02-143:403 reply I owned a C64. Remember how buttery smooth the interfaces of those '80s computers were?
By cryptonector 2026-02-146:01 Not Apples. But Amigas, omg those were smooth.
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.
By sedatk 2026-02-1517:06 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.
By ekianjo 2026-02-145:47 fewer layers between software and hardware...
By sedatk 2026-02-144:18 Modern browsers don’t repaint the whole screen every frame either.
By sehugg 2026-02-148:33 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.
By nozzlegear 2026-02-1415:111 reply 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.
By PantaloonFlames 2026-02-1417:301 reply 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?
By nozzlegear 2026-02-1418:46 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.
By khannn 2026-02-142:05 Notice how many times Claude Code was mentioned in this blog post nee advertisement?
By 1vuio0pswjnm7 2026-02-1416:19 To read using Firefox, or any browser/HTML pager, without Javascript or CSS:
( printf 'GET /blog/tuis-are-easy-now HTTP/1.0\r\n' printf 'Host: hatchet.run\r\n\r\n' )|busybox ssl_client hatchet.run \ |(echo "<meta charset=utf-8>";grep -o "<p.*</p>") > 1.htm firefox ./1.htmBy Aldipower 2026-02-1417:02 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! :-)
By NamlchakKhandro 2026-02-1415:09 imagine paying 3k$ for a laptop that can't even handle cubic gradients?
By 1vuio0pswjnm7 2026-02-144:13 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.
By dale_glass 2026-02-1323:022 reply 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).
By dwb 2026-02-148:32 Yes!
By dwb 2026-02-1412:27 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.
By skydhash 2026-02-143:48 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.
By chrysoprace 2026-02-141:202 reply 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.
By flomo 2026-02-148:54 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.
By chrysoprace 2026-02-149:271 reply 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.
By dwb 2026-02-1410:42 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.
By exceptione 2026-02-149:17 We do. We are only stubborn. Cross platform and low-footprint:
.net core => avalonia ui Java => JavaFX
By int_19h 2026-02-157:39 > 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:
$ 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 nowBy dwb 2026-02-140:04 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.
By dwb 2026-02-148:14 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.
By utilize1808 2026-02-142:124 reply 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.
By coldtea 2026-02-1414:15 >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!
By californical 2026-02-1416:57 I think their point was about “most popular” not necessarily meaning “better”. I don’t think they meant anything more by it
By troupo 2026-02-148:29 > 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.
By Pay08 2026-02-1412:33 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.
By chrisweekly 2026-02-142:54 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.
By einpoklum 2026-02-1418:39 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.
By jazzyb 2026-02-1416:06 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?
By JCattheATM 2026-02-182:19 That's no sure thing - plenty of vim users are new or not particularly knowledgeable, they just chose their village' for various reasons.
By troupo 2026-02-148:32 > 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.
By dwb 2026-02-1410:03 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.
By Brian_K_White 2026-02-143:33 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.
By 1718627440 2026-02-1411:441 reply 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.
By wredcoll 2026-02-1417:32 >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.
By dwb 2026-02-1410:00 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.
By einpoklum 2026-02-1418:31 > 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.)
By int_19h 2026-02-157:41 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.
By int_19h 2026-02-157:45 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.
By jxdxbx 2026-02-1418:15 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.
By dwb 2026-02-1418:44 Yeah, I sympathise. This is another angle on the sorry state of affairs we find ourselves in.
By worldsayshi 2026-02-141:23 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?
By worthless-trash 2026-02-146:381 reply > 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.
By worthless-trash 2026-02-1716:191 reply What.. no, its text.. I've seen it in view source..
You're talking about yet another 'presented' data stream, which is different than the character stream.
One can rebuild these at will, im sure.
The source of a web page is parsed to form DOM and accessibility trees. The character stream of a TUI can’t be parsed into anything similar because it is not given in a formal language that can express those structures.
By worthless-trash 2026-02-1913:38 We're going to have to disagree, if you consider the 'browser page' as the interface, it falls into the same problem you see with TUI's... you must reach into the DOM and accessibility information not via the character stream but with an API, the TUI has the same issue.
You've given me some great points to think about, thank you for the engaging conversation.
By JCattheATM 2026-02-182:16 I don't think most GUIs expose any more structure than TUIs.
> You’re forced to use it exactly the way it was designed and no different
So ... Like all Apple products?
By dwb 2026-02-148:18 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.
By fxtentacle 2026-02-140:181 reply 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
By dwb 2026-02-140:41 Did you reply to the correct post? Can’t see how it follows from mine.
By neomantra 2026-02-147:24 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...
