Why 'Stop Making TUIs' Split Developer Twitter Down the Middle

Install a developer tool in 2026 and there’s a good chance it runs in your terminal. Boxes, borders, colored progress bars, the whole retro-futurist aesthetic filling a black window. Then security researcher Thomas Ptacek said the quiet part loud: stop making TUIs, build local web apps instead. The developer community split cleanly in half, and the argument hasn’t cooled since.

What a TUI Actually Is

TUI stands for Text User Interface — a program that draws a full screen inside a terminal window and expects you to drive it with the keyboard. Picture a file list on the left, a preview pane on the right, no mouse required. That’s different from a CLI, where you type one command and get one blob of output back. A TUI paints and repaints the entire terminal. It’s an app living inside a terminal.

The canonical examples are lazygit for git, lazydocker for containers, and btop for system monitoring. The last few years produced a flood of them, mostly written in Rust and Go. Charm’s Bubble Tea framework has passed 30,000 GitHub stars. Rust developers reach for Ratatui. Building a TUI used to mean wrestling with low-level terminal escape codes; these frameworks dropped that barrier through the floor, and the ecosystem responded exactly the way you’d expect.

Ptacek’s Complaint

The argument is compact: you’re spending that effort on the wrong target.

Build a TUI and you are, functionally, reinventing a UI framework. Layout. Scrolling. Focus management. Text wrapping. Click handling. All of it, by hand. Meanwhile the browser shipped with every one of those solved, and it costs nothing. Spin up a tiny local HTTP server, open a browser window, and what takes hundreds of lines of terminal wrangling collapses into a few lines of CSS.

Then there’s accessibility, which is the part of the argument that’s hardest to wave away. Screen readers handle semantic HTML well. They do not handle a grid of box-drawing characters painted onto a terminal buffer. For a blind developer, a TUI is closer to a wall than an interface. Images and charts are easier on the web. So is copy-paste — anyone who has dragged a mouse across terminal output and picked up the box borders along with the text knows exactly what that costs.

So Why Did Everyone Run to the Terminal Anyway

The counterargument isn’t weak, and it has a specifically 2026 shape to it.

AI coding agents were the tipping point. Claude Code, Codex CLI, Gemini CLI, Aider — nearly every significant AI coding tool of the last two years chose the terminal. The reason isn’t nostalgia. What an agent does all day is read files, run commands, and parse output. That is the terminal’s native job description. Putting the interface where the agent already lives is the obvious move, not a stylistic one.

SSH matters too. If you work on remote machines, browser-based tooling is friction: set up port forwarding, open a local browser, get through auth. A TUI you just run. Wrap it in tmux and you can close your laptop with the session still alive on the other end.

Composability is the third pillar. Terminal tools pipe into each other. Output goes to grep, gets parsed by jq, feeds something else. Web apps don’t assemble that way, and no amount of good CSS changes that.

And weight. An Electron app can sit on 300MB of RAM while a comparable TUI runs in 10MB and launches instantly.

Both Sides Are Describing Different Programs

Arguments last this long when the two camps aren’t actually talking about the same thing. This is one of those.

Ptacek is aiming at the over-designed TUI — the ones that fill the screen like a dashboard, accept mouse clicks, and simulate tabs and modal popups in a text grid. He’s right about those. Reimplementing thirty years of browser refinement inside a terminal buffer is a bad trade no matter how good your framework is.

TUI defenders are describing something narrower: tools that attach to a terminal workflow. Staging a commit, scanning a log, killing a process. If you’re already in the terminal, finishing the task there is correct. Bouncing out to a browser and back is a context switch that costs more than the nicer widgets are worth.

A middle path keeps surfacing in these threads: ship both. Put the core logic behind a local server and let the interface be either a terminal client or a browser page, the way Jupyter separated kernel from frontend. Pick the surface that fits the moment instead of committing to one for the tool’s entire life.

The Question Isn’t Terminal or Web

It’s where the tool drops you. Already in the terminal? Finish there. Need to explore something visually, scrub a timeline, compare images? That’s a browser. Neither answer is universal, and pretending otherwise is how this argument stays unresolvable.

The actual failure mode is picking without deciding — reaching for a TUI because Bubble Tea makes it easy and everyone else is shipping one. That’s not a design choice, it’s a default.

So: what was the last dev tool you installed, and which side was it on? Were you glad it lived in your terminal, or did you just put up with it because that’s where it happened to be?