I think if you look purely at the numbers, the real reason TUIs are popular is claude code, everything else is background noise compared to it.
What originally got me excited to build TUIs was the concept of delivering apps over the wire via SSH. SSH apps resemble a browser in that way: no local installs required.
It's a major reason why I enjoy hacking on https://pico.sh -- deploying the TUI requires zero user involvement.
This is the case. The advent of libraries like Rich and others certainly helped, along with the trend of Rust TUIs for system programming/lack of good GUI options.
Better terminal emulators probably played a role too. In particular the newish Windows Terminal. The older cmd.exe console only supported Windows Console API. WinTerm has full VT and ANSI support, much better font rendering, and less importantly, mouse support and Sixel support.
This makes it much easier to build cross-platform TUIs. It used to be a chore, now it's probably easier than most GUI frameworks. (Possibly with the exception of Electron, but that comes with a different set of trade-offs.)
The console is conhost.exe. Conhost (Console Host) is the same kind of program as Windows Terminal, iTerm2, Konsole, Ghostty or Linux Console (the console that Linux uses on text mode)
The shell is cmd.exe (Command Prompt). This is the same kind of program as PowerShell (powershell.exe or the cross platform pwsh.exe), bash, zsh, fish etc. It's also similar to any TUI program such as Far Manager, mc (Midnight Commander), lazygit etc.
rust community likes tui ever since Ratatui and some other packages are making it easier than for example ncurses or notcurses etc. - i think Ratatui package is one big propellor for tui use and creation nowadays from slightly before claude code etc.
Disagree; TUIs were already gaining steam before that.
I think the main driver was frameworks, available for a range of languages, that make it easy to create nice-looking TUIs (ratatui, textual, ink, etc.)
Claude code amplified the trend hundred fold but there was already a significant increase of TUI since the days of go fzf, rust ratatui and python rich.
My bet would be a desire to do away with heavy browser based UI and the curiosity of trying to test the limits of terminal based rendering.
TUI is popular because a) there are no native GUI frameworks for simple tools that are easy, fast, and simple to develop in at the same time, and b) low fidelity lets you pretend being a UI/UX developer without really being one. The rest is abysmal. It's not automatable at all (the article is wrong on that point), less readable (monospace/no images), very limited (try making a DAW in it...), relies on a ton of ancient cruft in Unix-related terminals, it's not really portable etc etc.
I'd argue that UX these days jumped the shark and that TUI constraints brings back some desirable simplicity, although I agree that they like automation.. but I would bet a few dollars that it's far from impossible (and a fun challenge). People are creative, I wouldn't be surprised if someone made a fun miniDAW in a TUI.
I think he probably wouldn't classify CMI UI as TUI. It was monochrome and without true type fonts like terminals, but it allowed for pixel drawing it seems. It's a hybrid.
"there are no native GUI frameworks for simple tools that are easy, fast, and simple to develop in at the same time" - Tcl/Tk does all that just fine for me.
> What originally got me excited to build TUIs was the concept of delivering apps over the wire via SSH. SSH apps resemble a browser in that way: no local installs required.
It's a shame that a serial port typewriter emulator has somehow managed to stay alive. Instead of building new and exciting system based on new and exciting technology we get GPU accelerated typewriter emulators. It's a weird form of tech blindness mixed with nostalgia. Why arent we moving on? ssh? You can pipe whatever protocol over ssh.
I would really prefer if we moved on and worked on drawing to remote bit mapped displays. We have examples to learn from: X windows was network transparent though not a well thought out design (see audio.) Plan 9 has devdraw, an rpc based rendering engine that you load assets into then issue draw commands over the wire from a remote graphics program.
We see this today - there are plenty of protocols to support rendering applications over the wire (vnc, rdp, x-forwarding, waypipe, broadway, etc...)
They get very, very little usage outside of highly technical spaces. The demand just isn't there.
What did get there was the browser - which solved this problem quite nicely for basically every desired use-case, and has the benefit of offloading most of the computation to the remote device.
---
And as an aside - text remains a wonderful medium, with an incredible amount of composition and flexibility. The issue with GUI systems is that output != input. And it turns out that matters quite a bit, and is unavoidably limiting.
I'm pretty sure you could create an HTML based calculator app pretty easily with minimal overhead. Hell monaco (editor in VS Code) is massive by comparison to most apps... there's very little reason most line of business needs and simple apps can't or shouldn't be done in browser.
You get composition, scaling, accessibility features and a host of other benefits in the box that any other toolkit for GUI adds a lot of developer overhead.
Recently, I have used both Zed[0] and VSCode[1] remotely via SSH. It works just fine, and it was painless to set up. I remember years ago last time I tried, it was a much harder process.
In Emacs it's been easy for a long time. Just use /ssh:user@host:path/to/file and it appears local. The added advantage, which I am not sure is supported by most editors is that if you want you can use the remote environment for builds, tests, etc. Like if I C-c C-c a defun it gets compiled and updated in the remote running image.
> I think if you look purely at the numbers, the real reason TUIs are popular is claude code
Do you mean that TUIs are popular because everyone is now trying to imitate Claude Code? or because TUIs are now easier to develop when Claude Code exists?
CC demonstrated that one can have a powerful, flexible and responsive interface in a terminal, and to have that for a piece of software that has wide mass market appeal. I don't think we've seen this since WP5.1 . (Personal opinion: the CC terminal application beats their desktop software hands down in usability. That said, the desktop software is a lot better for corporate email trawls and helping to iterate on visualisations.)
Then for prospective devs, CC makes it easy to sling (and debug!) code that handles the various terminal vagaries with much less headache. No need to care about manually maintaining control code state machines; no worries about a missed SIGWINCH handler screwing up your in-window layout on resize or font size change; much easier integration with available CLI tools.
I have written some ncurses/C code in my time. I wouldn't want to do that by hand again.
I got excited about TUIs when I was exposed to the Bubble Tea framework for Go. I'm sure that Claude has accelerated the trend, but interesting things were already happening years ago.
That's why I started creating TUI apps. The cli was increasingly becoming a main view for daily work. I was using shortcuts to put the terminal side by side with other desktop apps or browser windows for context, but it was nicer to just write something that could sit in a tmux or zellij session next to claude or opencode.
It's also nice to have a little less to worry about as a desktop application developer, to be honest. The display is less nice (low text density especially) in exchange.
It's not really a tui. At least that's not the reason for its success.
It's a place where a human can talk to an agent with a common language (human language) and use the computer together in an environment that works for both of us. Text commands and text results.
I use the Code tab in the Claude Desktop App and find that a superior experience since everything you expect from a desktop app works: copy/paste, undo/redo, automatic formatting of text as you type it, multiline input etc which just doesn’t in the TUI. It requires preparing th environment a little bit so that when Claude runs commands it has the same access as a terminal but I got it working easily enough.
All of those: copy/paste, undo/redo, multiline input work for me in my TUI. I wonder if different environments have different behaviors. (Not sure about automatic formatting of text. I usually format my text manually.)
It works differently and in a much more limited manner. Can you select text in the middle of a prompt and delete it? Can you paste anywhere? How do you enter multiline input?? That cannot work unless explicitly handled by the app, terminals don’t have a general way to do it in a TUI. The formatting I am talking about is color highlighting and block code snippets. If you have a terminal that can do that do let me know!!
What originally got me excited to build TUIs was the concept of delivering apps over the wire via SSH. SSH apps resemble a browser in that way: no local installs required.
It's a major reason why I enjoy hacking on https://pico.sh -- deploying the TUI requires zero user involvement.