I think part of it is also that we're able to still LARP as full developers of complex systems while vibe coding by seeing an interface that makes us look like l33t h4xx0rs even though we're just pressing continue 15 times
> look like l33t h4xx0rs even though we're just pressing continue 15 times
I feel seen.
I also think there’s a certain element of reacting against absolutely everything becoming a bloated electron app.
I have no doubt - if it hasn’t already happened - that some apps will unironically embrace the most ridiculous option by shipping as electron apps that implement a TUI layer as their front-end.
> I have no doubt - if it hasn’t already happened - that some apps will unironically embrace the most ridiculous option by shipping as electron apps that implement a TUI layer as their front-end.
Considering the insane memory consumption of claude code running in my terminal, electron was never really the problem, bad software was the culprit all along.
Bad UI plagued software development since ages immortal. The reason is not AI. Good UI design is a skill (or art?) and not an afterthought. But most people do not see it that way and that is why things are the way they are.
I’m relatively certain it’s just this at the end of the day. Everything I see people doing in their custom built TUIs or claude/codex CLI can be done, likely even easier, in a simplified IDE or easier to scan UI, but it feels nice/cool/cyberpunk/work-like to look like you’re doing more.
Everyone will have a “reasonable” explanation though for why they have to stay in the terminal even when they aren’t really coding anymore and it wouldn’t be hard to have a window next to your terminal if you really have to, but live and let live. Whatever makes you happy as be all become managers.
I too like a cyberpunk interface even if it’s last the need :)
It is much easier to quickly generate a usable tui for simple monitoring and management than a usable gui. Go + lipgloss + bubble tea and a single prompt will give you whatever you need in a minute or two - much faster to compile and no platform specific issues. I can’t speak for anyone else, but I do a lot of work in the terminal still and I’d much rather stay in that context then open up yet another window
> I can’t speak for anyone else, but I do a lot of work in the terminal still and I’d much rather stay in that context then open up yet another window
I do a lot of work in the terminal and that's exactly why I'd rather have other windows to the side so that my terminal can stay exactly focused on what I'm doing there. Those other windows might also be terminals, but I have a big screen, and I want to make use of it to see things all at once. A GUI gives far more flexibility for arranging those multiple views.
I've sat with coworkers taking two to twelve keystrokes to flip between things that I just have side by side in separate IDE windows, browser windows, or tabs... or can switch between with a single click instead of those keystrokes.
No it can never be the same. The terminal is about not having to switch from the keyboard. My entire workflow is tmux panes with different TUIs and terminals. Not to mention performance, with a neovim IDE you may have tens of them open in different panes for example. I wouldn't try that with VSCode.
TUIs already increased in popularity before agents became a thing. The low latency, the ease of remoting and the limited screen real estate which forces the developer to carefully design the interface are genuine advantages. I've been using mutt, vim, tig, tmux, newsboat, etc for over a decade at this point, and the cyberpunk feeling faded quickly.
I don't know I probably went for tui/cli for all my own tooling because it's just easier to develop in the past. Even when vibing not having a gui saves mental overhead for me. Vibe coding made computing a lot more personal for me and I like not using my mouse all the time.
I mean, I guess there's that novelty for the first few years of your career. I've been doing this a decade. I don't care about looking and feeling like a l33t h4xx0r and I doubt my peers do either.
TUIs just solve the right problems in the same world we're already working in - the terminal. That they're fast to launch and terminals have modern features like rich color and mouse support just adds to that.
Because now we have a young generation nostalgic of their parents experience in the 1980's, and that includes the TUI experiences we were stuck with back in the day.
The diagnosis for GNU/Linux is better than I expected but I think is still incomplete. Yes, you have two major toolkits (GTK+ and Qt) and many minor ones (most of which wrap one of the majors). Qt is proprietary but also available under a free software licence, but what if you don't want that that complexity? It feels like modern GTK+ is less of a cross-platform toolkit and more of a runtime layer for libaidwaita and the GNOME stack. So if you don't want to conform to GNOME's UI conventions, it's not clear where else to go.
Also, the explosion of new languages in recent years means having to write a new set of FFI wrappers around existing libraries, and it's easier to make an idiomatic library for TUI development than wrap all of GTK+ or Qt.
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.
Contrary to what the article says ("but Google gave up on the project before a real product was launched"), I think Flutter work continues and adoption is increasing
I mean, both wxWidgets and Qt are fine, no? GTK 2 and 3 as well (4+ is... meh). There are plenty applications using one of these (often via python bindings).
I think it is more of a staffing problem. Plenty of people know web development, so you want to use those people for desktop as well. Having desktop be JS (electron) helps a lot with that.
To me the worst case is trying to develop some small utility like a tool to search in files using regex. Because if you are developing something large, the amount of time you spend dealing with packaging, distribution, etc., is small and you don't care about file sizes.
But if I want to, say, develop the app for Windows. That is easy. You get a tiny binary to just opens a form and runs with a double click. No install necessary.
The same thing on Linux? Impossible. There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained you need to ship the entire OS. Now your file size is huge. I can't use Python, because now Windows users need to have Python or I have to ship an interpreter.
The only plausible alternative is something like Java. Now you have a single .jar file that runs on any system. But then Oracle changed the license, and JavaFX is no longer part of Java (Swing still is).
Honestly, I just want to display a menubar with keyboard shortcuts. Why can't there be a menubar VM or something that gives me access to a menubar on all OS's without having to deal with all of this. We are already shipping the entire browser with Electron. That is stupid. The way it should work is users install a something like Flash but for desktop apps and every app just uses that platform.
It's probably easier to ship a DOS game than a desktop app because everyone who wants to run a DOS game will just have a DOS emulator installed.
Zed did. I know it has it's fans, but it doesn't seem to be generating a stampede of adoption despite what looks like a monumental effort to build a GUI system from the ground up.
> The hardcore, moved to vim or emacs, trading immediate feedback and higher usability for the steepest learning curve I’ve seen
The only hard part about vim is to be forced to strecth the finger up to Escape for what is essentially the most essential functin in modal editor: Going back to command mode. The ideal workflow is do a quick edit and go back to command ("normal") mode instantly. The fact that it's Escape is a historical artifact that needs not be.
So just remap CapsLock to escape, it system-wide, it's not that hard and it's nice to have Escape there generally. In Linux and MacOS it's just a gui setting away and in windows you just have to edit (create?) a registry key. Can be done on any machine under a minute.
Apart from that I don't see where the learning curve is since you can just start with the basics from vim-tutor and learn more when you feel you're spending time on something. I already felt faster than in any other editor when I just knew the basics. The real problem of vim is that you get used to modal editing very quickly and it feels like the stone age when you don't have it.
Unfortunately, remapping escape to caps lock can lead to serious friction if you have to work with different laptops a lot, like I do. The muscle memory gets in the way a lot.
I always remap Caps Lock to Ctrl. I understand that Caps Lock needed to be next to Ctrl in typewriters, but in computers it seems like it is wasting a key in the home row for only be used sometimes for screaming (which can be done by holding shift...)
remapping capslock to esc is something nobody whom i've shamed into doing can go back from. it's just night and day. i've been thinking lately that the reason we need hjkl is vim is because the keyboard layout is actually bad for arrows. on typewriters there was no arrows, but on a computer arrows are of primary importance. i think the spacebar doesn't need to be so big, there's no reason for it to be available to both thumbs, and i think moving the small set of arrows into the left or right part of the spacebar position would be so much better for typing because the hjkl hack only work in hacker editors, but we need to use arrows a lot on normal software and it's super bad for your hand if you use it a lot. i started developing inflamations because of the way i fold my thumb to reach for the arrows without moving my entire hand.
> i think the spacebar doesn't need to be so big, there's no reason for it to be available to both thumbs
This is why I love JIS, even though I don't actually need the Japanese keys. That small spacebar is so much better, and you get three extra keys (Henkan, Muhenkan and Kana) along the bottom row. As an Emacs user, I bind Henkan and Muhenkan to be Control keys. It's very comfortable.
The TUIs I've looked at seem to be largely NPM dependent? Bizarre that agents apparently don't have time to rewrite themselves in something that isn't a security tire fire. It kind of makes me assume that all this agents taking over stuff is from people working at garbage-pivot-garbage startups that don't really have to worry about any consequences but not being fast enough.
Go + Lipgloss + Bubbletea is by far the most robust and performant stack for building (and or generating) aesthetic and usable TUIs. Excellent DX. No npm necessary
Yeah that’s the thing, pretty much all the people who are really into ai for everything are JavaScript/Typescript developers, usually working at startups, and often in the AI field.
I think the corollary to this is that there are more people comfortable with living in a terminal. TUIs are more common now that there is an increased audience for them.
There's nowhere in a TUI to add oceans of padding for a ""sleek"" and ""modern"" look. There's very very little that a product manager can ""streamline"" in 80 columns of text.
Using Claude has highlighted, for me, a number of issues with terminal apps like Claude Code. You can’t easily see the status of lots of instances, you can’t easily search for instances, you can’t get one instance to start another instance or send a message from one instance to another and, of course, if you make a slightly mistake in coding a full screen app, you get screen corruption.
I fully agree about the overall downward trend in quality and efficiency of GUI apps, but I also think there's an important factor in the rise of TUI apps:
People now have access to good terminal emulators. Back in the day, you had cmd.exe in Windows. Now you have a plethora of Linux/Unix terminal emulators, Terminal.app in MacOS, and Windows Terminal in Windows 10/11. These are quite capable applications able to render good, complex text-based interfaces.
There are a lot of points in there that are just generally bad in modern applications – e.g. UI inconsistencies, lack of automation and general configurability (shared ways to handle windows, layouts, keyboard shortcuts, etc.). I think it’s fair to say these things are just hugely lacking in modern operating systems. Linux might come close, but only with lots of tinkering. macOS is clearly lost and degrading now, and Windows was never close to having these qualities.
I don’t know if TUIs will be the answer, but it’s an interesting development!
I think the come back is completely driven by Claude Code. Claude Code is a TUI, Claude Code is successful, therefore let's make everything a TUI!
I'm pretty sure the success has nothing to do with the TUI though. I personally enjoy it a lot but the productivity boast doesn't come from avoiding the mouse.
It is driven by Claude Code, not because it's a TUI but because you can paste a bad TUI directly into CC and tell it to intuit what to fix, whereas uploading a screenshot is more cumbersome and less likely to be parsed correctly.
I am conflicted on tuis they are nice, convenient and I dig the aestetic. But they're often not composeable. So even if they're there they dont feel native to the terminal. It is just an app in the terminal and that is okay, but you lose some of the terminal magic
TUIs are great for low friction remote work. I do a lot of data processing work on remote VMs with a mix of interactive debugging/eyeballing and bulk jobs. TUIs are a great fit for the sorts of tools I build to support this work. The other UI paradigm I end up reaching for is locally hosted web UIs, as models are really good at one-shotting HTML reports with graphs and tables. Inside VS code those get automatically tunneled to the local machine.
servo was recently published on crates – it has potential of becoming new standard; electron model proved to work very well the only downside is monstrous memory usage.
> The most popular claim is the memory consumption, which to be fair has been decreasing over the last decade, but my main complaint (as I usually drive a 64GB RAM MacBook Pro) is the lack of visual consistency and lack of keyboard-driven workflows.
Lucky you. I avoid electron apps because I'm limping along with 16gb.
I do like TUIs but in the article it mentions Gnome style apps don't fit the look. That sounds like a limitation of Omarchy.
It's not too bad to theme GTK apps and have them all look a consistent way. For example I use Tokyonight Moon and Gruvbox and they both have GTK themes that look great for Firefox, Thunar, GIMP, LibreOffice and more. I don't use Omarchy but here's a few screenshots https://x.com/nickjanetakis/status/2037125261657883061/photo....
Nothing fancy was done on my end, just installed the specific GTK themes. They even support live reloading because GTK's tooling supports it, my dotfiles at https://github.com/nickjj/dotfiles handle all of it for you. I still prefer TUIs but you can have nice looking GUI apps for when you want them.
Because LLMs operate on text, and their purveyors claim natural language interfaces are the best thing since sliced bread, since that's what they sell.
the current AI summer has been great for us dorks that prefer TUI/console interfaces. I hope it all sticks around with the inevitable cool-down in LLM hype.
The best thing about TUIs is that they're so fast. They launch fast, run fast, and you use them fast. There's a learning curve for the bazillion hotkeys, because all it is is hot keys, but when you have it, you just fly.
I've been reverting more and more: mutt (mail), newsboat (RSS), amfora (gemini protocol), gurk (Signal), chawan (web), and even trn (Usenet). My RAM usage is tiny. Everything is quick.
GUIs should take a page from the TUI playbook and consider making the app keyboard-first. Nothing is more frustrating than a missing hotkey.
> They launch fast, run fast, and you use them fast.
I don't know about that. The Gemini TUI takes like four full seconds to start on my machine. I have no idea what the hell it's doing. A lot of the fancy new TUIs that are coming on the crest of the current fad are hot garbage. I hate them.
The tide is going to turn on this in the second half of 2026. There have always been nerds who just love TUIs, and still read their email in Mutt. But I think the subtext of this article is right, that TUIs are back because of how much of a pain UI development is.
But that's changed drastically in the last few months. I spent the weekend doing SwiftUI stuff with Claude, with a lot of success. It's going to get much easier to ship fast, solid, native UIs for things, and native UI is both very fun to build and also attractive to ordinary users.
(Fun green field for doing interesting UI work: do native UI for remote server stuff, like an htop UI that uses some dialect of SSH to fetch remote data.)
I think modern TUIs are a blip. A big, important blip. But a blip. The age of the Orc is over. The time of the Human Interface Guideline has come.
That still doesn't address the root of the problem, which is that TUIs and Electron apps are write-once, run-anywhere, while native GUI dev is insanely fragmented.
I mean, I guess that's more or less just a summary of the blog post, but it's true. And it will remain true until the fragmentation ends, and the fragmentation won't end until Microsoft gets its act together and ships their version of SwiftUI so that some sort of abstraction layer over SwiftUI/GTK/MsftUI can be created. And since Microsoft will almost certainly never get its act together, the problem will remain.
In other words, not a blip. The UIs of the present and future will all be Electron apps and TUIs.
What does it matter how fragmented the platforms are? I feel like this isn't sinking in with people. I was chatting with a friend last night about a SwiftUI app that I'd built and he'd pitched in on. He then reimplemented --- didn't port it, reimplemented it, for WinUI, that night, with just a couple prompts.
I am, in a proverbial sense, buying puts on Electron.
That's really not a solution. You're not targeting the host OS for that, which instantly kills that approach for everything other than "we need this to run on Linux and don't care how." You're shipping all of WINE with it. You're sticking out like a sore thumb with Win32 widgets next to the rest of your GTK apps. Etc etc etc.
I think another factor is that people are rejecting the rounded corners and excessive padding of modern web design, you can't do that in a TUI, so you don't have a designer or standard practice encouraging you to do it. As implemented TUIs have greater information density than GUIs. Make no mistake though, TUIs are a decided step backwards from GUIs. Everything that you can express via text, you can also do in a text area on a GUI app.
I think TUI's are popular because they're easier to make than a GUI. They are much more constrained. A TUI is basically a wire frame with some colours, whereas with a GUI the wireframe is only the first step.
Are you sure about that? Most GUI toolkits have things so wired up that it’s trivial to get a small app running. The point is to get a dev up and running as quickly as possible (even if there is a lot of magic involved). If you’re okay with the defaults, it ca be very quick to get a GUI up and running.
In contrast, most TUI toolkits generally require the developer to wire things up manually. Maximum developer flexibility, but with a decent learning curve. Having an LLM available to handle the initial wiring definitely speeds things up.
I know I had a few long lasting bugs with a TUI I wrote years ago that Claude was able to find the fix for pretty quickly. These were bugs that weren’t obvious to me, partially due to the arcane nature of working within a TUI.
Nothing inherently special or even superior about TUIs, I think this very simply just speaks to "what happened" which is the fragmentation of the GUI space over the course of Microsoft v Apple v Linux v "The Web."
Seems like it could have gone differently. Feels like the time could be ripe for something like a "declarative gui spec."
My cynical take why TUIs are back is because people operating in the terminal became a signal that you were competent and once people figured that out everybody started doing it. The reason people were operating in the terminal is lost of them but hey it makes you look like a 1337 hacker. It's the same thing with side projects of past decades. People who had side projects cared about the craft for more than a paycheck and tended to be more competent. Then every person just trying to land a job suddenly had "side projects". Gotta have those green squares on github.
> My cynical take why TUIs are back is because people operating in the terminal became a signal that you were competent and once people figured that out everybody started doing it
I've got a bit of a different on it... It's because TUIs do lend themselves better to automation (it's been mentioned in the thread) and, most importantly, it's because there's less cognitive dissonance between a TUI and how it typically operates and... The way AIs are using command line tools / the terminal (or a REPL, for those using agents hooked to a REPL).
In a way AI agents are validating what us old-timers always knew: the CLI and TUIs is the most powerful way. And AI tools didn't choose the most common dev environment: devs using fat IDEs (and btw I was already using IntelliJ IDEA back when some people were still arguing NetBeans was better than IntelliJ) are way more common than those piping Unix commands to achieve even simple tasks. Instead AI tools did choose the most powerful way to work: and that's piping terminal commands and SSH/tmux/TUIs.
When the tool itself, like Claude Code CLI, is immediately showing the outputs of piped Unix commands and allowing to run commands from a prompt and is, itself, a TUI, it's validating that it's an extremely powerful way to work.
A Claude Code CLI (or similar) TUI in a tmux session is something quite powerful.
Then you combine that with the fact that techs like LSP and tree-sitter did at least partially commodotize the IDE and suddenly TUIs (or things very close to it, like GUI Emacs: which can do graphics but is still mostly used as a TUI tool) do look very appealing.
Magit is considered by many --even non Emacs user-- as the best Git interface ever. It's text, text and more text.
My life is terminals (text), Git and Magit (text), Emacs (GUI but basically text), SSH (text), tmux (text), many text things I forgot and now TUI harnesses.
If you're modelizing in Blender or editing movies or creating movies, a GUI makes sense. But if you write code, which is text, all you need is text, text and more text.
TUIs are making a comeback because it is all text and AI agents are proof of that.
Only for software engineers who are already familiar with terminals. Most non tech people I know and in my company absolutely hate TUI. Even a fraction of software developers who spend most their time outside terminals (especially those that are on Windows and/or use specialized tools/IDEs) prefer to avoid TUIs as well.
One huge advantage that the commandline + TUIs have is ... speed.
I get more things done, in most cases, than via a GUI. In a way a
TUI is a GUI of course, but with the focus on keyboard use and
inputting instructions/commands. Most GUIs seem to be centered
around keyboard AND mouse and then try to make things convenient
here for those operations, such as drag-and-drop via the mouse.
TL;DR, not from the article: Because Claude Code was a small team experiment done months after Claude Sonnet 3.7 had support for file editing; a bunch of companies had to fast follow; and the path of least resistance / collaborative work between PM and dev and design is copying, and companies are companies, they prefer money and competition over patiently waiting for X00 people to decide on a vision and deliver it.
I think it's important to note this because it's not great. Either I'm having a fever dream, or, someone will GUI this stuff and it'll be a gamechanger.
The real reason TUIs are back is not one reason, but a host of reasons.
The biggest current reason is fashion. Tools like Claude Code did it, and while they actually had good reasons to run in the terminal, the tools' popularity and wildly different look, especially to non-terminal-native users became a signal of some positive sort.
I don't believe that any of the rationale posed in the article is a popular reason developers are using.
I think part of it is also that we're able to still LARP as full developers of complex systems while vibe coding by seeing an interface that makes us look like l33t h4xx0rs even though we're just pressing continue 15 times
> look like l33t h4xx0rs even though we're just pressing continue 15 times
I feel seen.
I also think there’s a certain element of reacting against absolutely everything becoming a bloated electron app.
I have no doubt - if it hasn’t already happened - that some apps will unironically embrace the most ridiculous option by shipping as electron apps that implement a TUI layer as their front-end.
> I have no doubt - if it hasn’t already happened - that some apps will unironically embrace the most ridiculous option by shipping as electron apps that implement a TUI layer as their front-end.
Claude code is almost there
https://levelup.gitconnected.com/theres-a-react-app-running-...
Considering the insane memory consumption of claude code running in my terminal, electron was never really the problem, bad software was the culprit all along.
Can’t say that electron does not encourage bad software, quite the opposite
It's an example of bad code that further encourages more bad code.
Always has been.
Just wait till you hear about the wonders of React + Ink! Now you can have JS bloat in your terminal too!
Jokes aside, I don't understand how devs can bring themselves to ship such inefficient apps.
Bad UI plagued software development since ages immortal. The reason is not AI. Good UI design is a skill (or art?) and not an afterthought. But most people do not see it that way and that is why things are the way they are.
> since ages immortal
since time immemorial?
3rd Sept 1189.
Anything after that is time memorial I guess.
I’m relatively certain it’s just this at the end of the day. Everything I see people doing in their custom built TUIs or claude/codex CLI can be done, likely even easier, in a simplified IDE or easier to scan UI, but it feels nice/cool/cyberpunk/work-like to look like you’re doing more.
Everyone will have a “reasonable” explanation though for why they have to stay in the terminal even when they aren’t really coding anymore and it wouldn’t be hard to have a window next to your terminal if you really have to, but live and let live. Whatever makes you happy as be all become managers.
I too like a cyberpunk interface even if it’s last the need :)
It is much easier to quickly generate a usable tui for simple monitoring and management than a usable gui. Go + lipgloss + bubble tea and a single prompt will give you whatever you need in a minute or two - much faster to compile and no platform specific issues. I can’t speak for anyone else, but I do a lot of work in the terminal still and I’d much rather stay in that context then open up yet another window
> I can’t speak for anyone else, but I do a lot of work in the terminal still and I’d much rather stay in that context then open up yet another window
I do a lot of work in the terminal and that's exactly why I'd rather have other windows to the side so that my terminal can stay exactly focused on what I'm doing there. Those other windows might also be terminals, but I have a big screen, and I want to make use of it to see things all at once. A GUI gives far more flexibility for arranging those multiple views.
I've sat with coworkers taking two to twelve keystrokes to flip between things that I just have side by side in separate IDE windows, browser windows, or tabs... or can switch between with a single click instead of those keystrokes.
It’s very easy to do the same thing in a variety of ways and simple guis are basically solved by Claude/codex for almost anything.
Not anymore it isn't. "Claude, make this a web app".
Just what I need! A bloated react app to manage my systemd units
No it can never be the same. The terminal is about not having to switch from the keyboard. My entire workflow is tmux panes with different TUIs and terminals. Not to mention performance, with a neovim IDE you may have tens of them open in different panes for example. I wouldn't try that with VSCode.
Hot take: TUI’s default to providing utility, GUI’s are prone to extra style/bloat.
Obviously both are capable of the other.
The vanilla HTML styles look bare, so you have do _something_. TUI’s look sort of cool in their simplest form.
It isn't, at least for me. I choose between GUI and terminal apps based on which one is easies. Sometimes the "easy" option really isn't easy at all.
TUIs already increased in popularity before agents became a thing. The low latency, the ease of remoting and the limited screen real estate which forces the developer to carefully design the interface are genuine advantages. I've been using mutt, vim, tig, tmux, newsboat, etc for over a decade at this point, and the cyberpunk feeling faded quickly.
I don't know I probably went for tui/cli for all my own tooling because it's just easier to develop in the past. Even when vibing not having a gui saves mental overhead for me. Vibe coding made computing a lot more personal for me and I like not using my mouse all the time.
I mean, I guess there's that novelty for the first few years of your career. I've been doing this a decade. I don't care about looking and feeling like a l33t h4xx0r and I doubt my peers do either.
TUIs just solve the right problems in the same world we're already working in - the terminal. That they're fast to launch and terminals have modern features like rich color and mouse support just adds to that.
Because now we have a young generation nostalgic of their parents experience in the 1980's, and that includes the TUI experiences we were stuck with back in the day.
The diagnosis for GNU/Linux is better than I expected but I think is still incomplete. Yes, you have two major toolkits (GTK+ and Qt) and many minor ones (most of which wrap one of the majors). Qt is proprietary but also available under a free software licence, but what if you don't want that that complexity? It feels like modern GTK+ is less of a cross-platform toolkit and more of a runtime layer for libaidwaita and the GNOME stack. So if you don't want to conform to GNOME's UI conventions, it's not clear where else to go.
Also, the explosion of new languages in recent years means having to write a new set of FFI wrappers around existing libraries, and it's easier to make an idiomatic library for TUI development than wrap all of GTK+ or Qt.
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.
I don't think that's true, because it appears to me that the upswing in new TUI programs predates Claude Code's takeoff.
Claude Code uses Ink, a react library in javascript for UI. The upswing is probably stuff like this making it super easy to write a TUI.
What a fascinating modern age we live in.
Because nobody is investing in native UI development. Electron is proof that if there were a simple to use GUI stack that companies would adopt it.
Contrary to what the article says ("but Google gave up on the project before a real product was launched"), I think Flutter work continues and adoption is increasing
I don't think it is lack of investment necessarily, so much as not building the right thing.
What we need is a framework that is easy to use, cross platform, open source, and ideally can be used from your programming language of choice.
I mean, both wxWidgets and Qt are fine, no? GTK 2 and 3 as well (4+ is... meh). There are plenty applications using one of these (often via python bindings).
I think it is more of a staffing problem. Plenty of people know web development, so you want to use those people for desktop as well. Having desktop be JS (electron) helps a lot with that.
To me the worst case is trying to develop some small utility like a tool to search in files using regex. Because if you are developing something large, the amount of time you spend dealing with packaging, distribution, etc., is small and you don't care about file sizes.
But if I want to, say, develop the app for Windows. That is easy. You get a tiny binary to just opens a form and runs with a double click. No install necessary.
The same thing on Linux? Impossible. There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained you need to ship the entire OS. Now your file size is huge. I can't use Python, because now Windows users need to have Python or I have to ship an interpreter.
The only plausible alternative is something like Java. Now you have a single .jar file that runs on any system. But then Oracle changed the license, and JavaFX is no longer part of Java (Swing still is).
Honestly, I just want to display a menubar with keyboard shortcuts. Why can't there be a menubar VM or something that gives me access to a menubar on all OS's without having to deal with all of this. We are already shipping the entire browser with Electron. That is stupid. The way it should work is users install a something like Flash but for desktop apps and every app just uses that platform.
It's probably easier to ship a DOS game than a desktop app because everyone who wants to run a DOS game will just have a DOS emulator installed.
I want to say you could statically link a GUI application, but I'm pretty sure libpthread doesn't cooperate on static linking.
Zed did. I know it has it's fans, but it doesn't seem to be generating a stampede of adoption despite what looks like a monumental effort to build a GUI system from the ground up.
> The hardcore, moved to vim or emacs, trading immediate feedback and higher usability for the steepest learning curve I’ve seen
The only hard part about vim is to be forced to strecth the finger up to Escape for what is essentially the most essential functin in modal editor: Going back to command mode. The ideal workflow is do a quick edit and go back to command ("normal") mode instantly. The fact that it's Escape is a historical artifact that needs not be.
So just remap CapsLock to escape, it system-wide, it's not that hard and it's nice to have Escape there generally. In Linux and MacOS it's just a gui setting away and in windows you just have to edit (create?) a registry key. Can be done on any machine under a minute.
Apart from that I don't see where the learning curve is since you can just start with the basics from vim-tutor and learn more when you feel you're spending time on something. I already felt faster than in any other editor when I just knew the basics. The real problem of vim is that you get used to modal editing very quickly and it feels like the stone age when you don't have it.
> The only hard part about vim is to be forced to strecth the finger up to Escape
I still don't understand why people keep mentioning this, ctrl-c works as well to go back to the normal mode.
> windows you just have to edit (create?) a registry key
Or use Powertoys, which I don't know why it isn't a setting.
(saying as a Mac, Linux and Emacs user, although I still use Vim in the terminal)
Unfortunately, remapping escape to caps lock can lead to serious friction if you have to work with different laptops a lot, like I do. The muscle memory gets in the way a lot.
I always remap Caps Lock to Ctrl. I understand that Caps Lock needed to be next to Ctrl in typewriters, but in computers it seems like it is wasting a key in the home row for only be used sometimes for screaming (which can be done by holding shift...)
If only keyboard makers would just always put escape there.
It should always be "hold for control" and "tap for esc".
remapping capslock to esc is something nobody whom i've shamed into doing can go back from. it's just night and day. i've been thinking lately that the reason we need hjkl is vim is because the keyboard layout is actually bad for arrows. on typewriters there was no arrows, but on a computer arrows are of primary importance. i think the spacebar doesn't need to be so big, there's no reason for it to be available to both thumbs, and i think moving the small set of arrows into the left or right part of the spacebar position would be so much better for typing because the hjkl hack only work in hacker editors, but we need to use arrows a lot on normal software and it's super bad for your hand if you use it a lot. i started developing inflamations because of the way i fold my thumb to reach for the arrows without moving my entire hand.
> i think the spacebar doesn't need to be so big, there's no reason for it to be available to both thumbs
This is why I love JIS, even though I don't actually need the Japanese keys. That small spacebar is so much better, and you get three extra keys (Henkan, Muhenkan and Kana) along the bottom row. As an Emacs user, I bind Henkan and Muhenkan to be Control keys. It's very comfortable.
The TUIs I've looked at seem to be largely NPM dependent? Bizarre that agents apparently don't have time to rewrite themselves in something that isn't a security tire fire. It kind of makes me assume that all this agents taking over stuff is from people working at garbage-pivot-garbage startups that don't really have to worry about any consequences but not being fast enough.
Return to the halcyon security era of curl piped into bash
Go + Lipgloss + Bubbletea is by far the most robust and performant stack for building (and or generating) aesthetic and usable TUIs. Excellent DX. No npm necessary
Is the Go ecosystem really that much better? As an outsider it looks like there's a fair amount of library use, more than I'd like.
Check out the Crush agent harness. It's very impressive.
Yeah that’s the thing, pretty much all the people who are really into ai for everything are JavaScript/Typescript developers, usually working at startups, and often in the AI field.
To me it's just that they're great for people who live in a terminal
- No distractions from visual content
- Extreme efficiency with keyboard
- AIs can code them up quickly. It used to be a total pain
I think the corollary to this is that there are more people comfortable with living in a terminal. TUIs are more common now that there is an increased audience for them.
There's nowhere in a TUI to add oceans of padding for a ""sleek"" and ""modern"" look. There's very very little that a product manager can ""streamline"" in 80 columns of text.
> - AIs can code them up quickly. It used to be a total pain
As far my opinion goes, this is biggest (and really only) reason.
Using Claude has highlighted, for me, a number of issues with terminal apps like Claude Code. You can’t easily see the status of lots of instances, you can’t easily search for instances, you can’t get one instance to start another instance or send a message from one instance to another and, of course, if you make a slightly mistake in coding a full screen app, you get screen corruption.
I don't think it is surprising. Loading entire chrome processes for simple super laggy UIs is just unbearable.
TUI are snappy, accessible over ssh, small screen friendly, easily embeddable in zellij or other multiplexers, easy to copy paste from... Amazing.
There are a lot of TUIs in existence worth looking at if one is interested or curious about them [0], [1], [2]
https://github.com/rothgar/awesome-tuis
https://terminaltrove.com/explore/
https://github.com/ibraheemdev/modern-unix
Even before Claude Code, I always see htop as the prime example of a good TUI.
I fully agree about the overall downward trend in quality and efficiency of GUI apps, but I also think there's an important factor in the rise of TUI apps:
People now have access to good terminal emulators. Back in the day, you had cmd.exe in Windows. Now you have a plethora of Linux/Unix terminal emulators, Terminal.app in MacOS, and Windows Terminal in Windows 10/11. These are quite capable applications able to render good, complex text-based interfaces.
There are a lot of points in there that are just generally bad in modern applications – e.g. UI inconsistencies, lack of automation and general configurability (shared ways to handle windows, layouts, keyboard shortcuts, etc.). I think it’s fair to say these things are just hugely lacking in modern operating systems. Linux might come close, but only with lots of tinkering. macOS is clearly lost and degrading now, and Windows was never close to having these qualities.
I don’t know if TUIs will be the answer, but it’s an interesting development!
I think the come back is completely driven by Claude Code. Claude Code is a TUI, Claude Code is successful, therefore let's make everything a TUI!
I'm pretty sure the success has nothing to do with the TUI though. I personally enjoy it a lot but the productivity boast doesn't come from avoiding the mouse.
It is driven by Claude Code, not because it's a TUI but because you can paste a bad TUI directly into CC and tell it to intuit what to fix, whereas uploading a screenshot is more cumbersome and less likely to be parsed correctly.
I am conflicted on tuis they are nice, convenient and I dig the aestetic. But they're often not composeable. So even if they're there they dont feel native to the terminal. It is just an app in the terminal and that is okay, but you lose some of the terminal magic
TUIs are great for low friction remote work. I do a lot of data processing work on remote VMs with a mix of interactive debugging/eyeballing and bulk jobs. TUIs are a great fit for the sorts of tools I build to support this work. The other UI paradigm I end up reaching for is locally hosted web UIs, as models are really good at one-shotting HTML reports with graphs and tables. Inside VS code those get automatically tunneled to the local machine.
servo was recently published on crates – it has potential of becoming new standard; electron model proved to work very well the only downside is monstrous memory usage.
> The most popular claim is the memory consumption, which to be fair has been decreasing over the last decade, but my main complaint (as I usually drive a 64GB RAM MacBook Pro) is the lack of visual consistency and lack of keyboard-driven workflows.
Lucky you. I avoid electron apps because I'm limping along with 16gb.
I do like TUIs but in the article it mentions Gnome style apps don't fit the look. That sounds like a limitation of Omarchy.
It's not too bad to theme GTK apps and have them all look a consistent way. For example I use Tokyonight Moon and Gruvbox and they both have GTK themes that look great for Firefox, Thunar, GIMP, LibreOffice and more. I don't use Omarchy but here's a few screenshots https://x.com/nickjanetakis/status/2037125261657883061/photo....
Nothing fancy was done on my end, just installed the specific GTK themes. They even support live reloading because GTK's tooling supports it, my dotfiles at https://github.com/nickjj/dotfiles handle all of it for you. I still prefer TUIs but you can have nice looking GUI apps for when you want them.
Somewhat ironic is that people are using them to create generic web apps like they are going out of fashion.
TUIs are back because the web got too bloated.
Because LLMs operate on text, and their purveyors claim natural language interfaces are the best thing since sliced bread, since that's what they sell.
the current AI summer has been great for us dorks that prefer TUI/console interfaces. I hope it all sticks around with the inevitable cool-down in LLM hype.
It was always there. k9s for instance, it started getting noticed recently. With coding agents, it is even easier to build.
The best thing about TUIs is that they're so fast. They launch fast, run fast, and you use them fast. There's a learning curve for the bazillion hotkeys, because all it is is hot keys, but when you have it, you just fly.
I've been reverting more and more: mutt (mail), newsboat (RSS), amfora (gemini protocol), gurk (Signal), chawan (web), and even trn (Usenet). My RAM usage is tiny. Everything is quick.
GUIs should take a page from the TUI playbook and consider making the app keyboard-first. Nothing is more frustrating than a missing hotkey.
> They launch fast, run fast, and you use them fast.
I don't know about that. The Gemini TUI takes like four full seconds to start on my machine. I have no idea what the hell it's doing. A lot of the fancy new TUIs that are coming on the crest of the current fad are hot garbage. I hate them.
Eh... no. Never underestimate people's ability to make software bloated and slow. You haven't spent enough time with Claude Code, Gemini CLI I guess.
Oh, I've definitely seen the results. :) But it's nice when people don't do that.
The tide is going to turn on this in the second half of 2026. There have always been nerds who just love TUIs, and still read their email in Mutt. But I think the subtext of this article is right, that TUIs are back because of how much of a pain UI development is.
But that's changed drastically in the last few months. I spent the weekend doing SwiftUI stuff with Claude, with a lot of success. It's going to get much easier to ship fast, solid, native UIs for things, and native UI is both very fun to build and also attractive to ordinary users.
(Fun green field for doing interesting UI work: do native UI for remote server stuff, like an htop UI that uses some dialect of SSH to fetch remote data.)
I think modern TUIs are a blip. A big, important blip. But a blip. The age of the Orc is over. The time of the Human Interface Guideline has come.
That still doesn't address the root of the problem, which is that TUIs and Electron apps are write-once, run-anywhere, while native GUI dev is insanely fragmented.
I mean, I guess that's more or less just a summary of the blog post, but it's true. And it will remain true until the fragmentation ends, and the fragmentation won't end until Microsoft gets its act together and ships their version of SwiftUI so that some sort of abstraction layer over SwiftUI/GTK/MsftUI can be created. And since Microsoft will almost certainly never get its act together, the problem will remain.
In other words, not a blip. The UIs of the present and future will all be Electron apps and TUIs.
What does it matter how fragmented the platforms are? I feel like this isn't sinking in with people. I was chatting with a friend last night about a SwiftUI app that I'd built and he'd pitched in on. He then reimplemented --- didn't port it, reimplemented it, for WinUI, that night, with just a couple prompts.
I am, in a proverbial sense, buying puts on Electron.
Why not instead have Linux just run Win32 applications?
That's really not a solution. You're not targeting the host OS for that, which instantly kills that approach for everything other than "we need this to run on Linux and don't care how." You're shipping all of WINE with it. You're sticking out like a sore thumb with Win32 widgets next to the rest of your GTK apps. Etc etc etc.
I think another factor is that people are rejecting the rounded corners and excessive padding of modern web design, you can't do that in a TUI, so you don't have a designer or standard practice encouraging you to do it. As implemented TUIs have greater information density than GUIs. Make no mistake though, TUIs are a decided step backwards from GUIs. Everything that you can express via text, you can also do in a text area on a GUI app.
I think TUI's are popular because they're easier to make than a GUI. They are much more constrained. A TUI is basically a wire frame with some colours, whereas with a GUI the wireframe is only the first step.
Are you sure about that? Most GUI toolkits have things so wired up that it’s trivial to get a small app running. The point is to get a dev up and running as quickly as possible (even if there is a lot of magic involved). If you’re okay with the defaults, it ca be very quick to get a GUI up and running.
In contrast, most TUI toolkits generally require the developer to wire things up manually. Maximum developer flexibility, but with a decent learning curve. Having an LLM available to handle the initial wiring definitely speeds things up.
I know I had a few long lasting bugs with a TUI I wrote years ago that Claude was able to find the fix for pretty quickly. These were bugs that weren’t obvious to me, partially due to the arcane nature of working within a TUI.
Idk, it's pretty trivial to set up a TUI with bubbletea or ratatui, and I assume other languages have similar libraries.
A reverse shibboleth for someone who does zero professional design work is taking a screenshot of differing corner radii in macOS.
Don’t fall for this.
Why? All the great designers I've worked with would have shivers shooting up their spine after looking at that screenshot.
There's something disgusting about the use of characters for graphs/charts on a bitmapped monitor. Nerds find a way to make stuff ugly!
Nothing inherently special or even superior about TUIs, I think this very simply just speaks to "what happened" which is the fragmentation of the GUI space over the course of Microsoft v Apple v Linux v "The Web."
Seems like it could have gone differently. Feels like the time could be ripe for something like a "declarative gui spec."
My cynical take why TUIs are back is because people operating in the terminal became a signal that you were competent and once people figured that out everybody started doing it. The reason people were operating in the terminal is lost of them but hey it makes you look like a 1337 hacker. It's the same thing with side projects of past decades. People who had side projects cared about the craft for more than a paycheck and tended to be more competent. Then every person just trying to land a job suddenly had "side projects". Gotta have those green squares on github.
> My cynical take why TUIs are back is because people operating in the terminal became a signal that you were competent and once people figured that out everybody started doing it
Are you saying GUI "the real deal"?
I've got a bit of a different on it... It's because TUIs do lend themselves better to automation (it's been mentioned in the thread) and, most importantly, it's because there's less cognitive dissonance between a TUI and how it typically operates and... The way AIs are using command line tools / the terminal (or a REPL, for those using agents hooked to a REPL).
In a way AI agents are validating what us old-timers always knew: the CLI and TUIs is the most powerful way. And AI tools didn't choose the most common dev environment: devs using fat IDEs (and btw I was already using IntelliJ IDEA back when some people were still arguing NetBeans was better than IntelliJ) are way more common than those piping Unix commands to achieve even simple tasks. Instead AI tools did choose the most powerful way to work: and that's piping terminal commands and SSH/tmux/TUIs.
When the tool itself, like Claude Code CLI, is immediately showing the outputs of piped Unix commands and allowing to run commands from a prompt and is, itself, a TUI, it's validating that it's an extremely powerful way to work.
A Claude Code CLI (or similar) TUI in a tmux session is something quite powerful.
Then you combine that with the fact that techs like LSP and tree-sitter did at least partially commodotize the IDE and suddenly TUIs (or things very close to it, like GUI Emacs: which can do graphics but is still mostly used as a TUI tool) do look very appealing.
Magit is considered by many --even non Emacs user-- as the best Git interface ever. It's text, text and more text.
My life is terminals (text), Git and Magit (text), Emacs (GUI but basically text), SSH (text), tmux (text), many text things I forgot and now TUI harnesses.
If you're modelizing in Blender or editing movies or creating movies, a GUI makes sense. But if you write code, which is text, all you need is text, text and more text.
TUIs are making a comeback because it is all text and AI agents are proof of that.
They were never really gone, just maybe introduced to a new audience a little more lately which is great.
Only for software engineers who are already familiar with terminals. Most non tech people I know and in my company absolutely hate TUI. Even a fraction of software developers who spend most their time outside terminals (especially those that are on Windows and/or use specialized tools/IDEs) prefer to avoid TUIs as well.
Hate to be this guy but it’s Xerox PARC, not Park.
Next one is the NoJS movement and Gemini or even Gopher spaces.
JS literally destroyed the software landscape. All the bad practices advertised as best.
One huge advantage that the commandline + TUIs have is ... speed.
I get more things done, in most cases, than via a GUI. In a way a TUI is a GUI of course, but with the focus on keyboard use and inputting instructions/commands. Most GUIs seem to be centered around keyboard AND mouse and then try to make things convenient here for those operations, such as drag-and-drop via the mouse.
TL;DR, not from the article: Because Claude Code was a small team experiment done months after Claude Sonnet 3.7 had support for file editing; a bunch of companies had to fast follow; and the path of least resistance / collaborative work between PM and dev and design is copying, and companies are companies, they prefer money and competition over patiently waiting for X00 people to decide on a vision and deliver it.
I think it's important to note this because it's not great. Either I'm having a fever dream, or, someone will GUI this stuff and it'll be a gamechanger.
> TUIs are Back
Citation needed?
The real reason TUIs are back is not one reason, but a host of reasons.
The biggest current reason is fashion. Tools like Claude Code did it, and while they actually had good reasons to run in the terminal, the tools' popularity and wildly different look, especially to non-terminal-native users became a signal of some positive sort.
I don't believe that any of the rationale posed in the article is a popular reason developers are using.
Fashion is a big driver for sure but TUIs do have advantages over GUIs that are real, especially for powerusers.