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 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.
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.
"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!!
> 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 function in a 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 Escape is used is a historical artifact that needs to be called out.
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 look up for more when you feel you're spending too much 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 Shift 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...)
I remap Caps Lock to Ctrl when held and to Esc when pressed - the best of both worlds when you live in Neovim. https://github.com/rvaiya/keyd works really well for me on Linux, but there is a similar software on MacOS.
I map it on all my computers, works well, if I end up in an environment where I don't have the mapping I just use Ctrl-[ or stretch.
When I end up helping other devs and use their non vim setups...now that really trips me up. Capitals everywhere, random hjkls ... I have to really slow myself down when using a "normal" editor.
Which is why I never went with CapsLock being both Ctrl and Escape depending of whether it's part of a key combo because it's whole setup. On the contrary, whenever I use someone else's machine I can quickly go in the settings, set the option and then set it off after I am done.
Weirdly enough I actually like that Esc is so far away and it is not for efficiency but for ergonomics. It forces me to lift my hand up and reposition it away from the home row and back so I'm forced to move muscles that would otherwise just wait around and collect RSI points. I tend to use the arrow keys often as well for the same reason on the other hand (although I do still use hjkl quite a bit still)
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.
I was just thinking this today tweaking the layout on my lilypad58, a layout I don't love and kept arriving at, "I just want more modifiers". Using JIS is genius.
I have left Control mapped to Meta, {,Mu}Henkan mapped to Control, Kana to right Alt, right Alt to Super, Menu to Compose/Meta (tap/hold) and right Control mapped to Greek.
I use keymapper[0] to do low-level remapping and tap/hold, and a custom XKB layout for the Greek modifier. I highly recommend this setup.
Yes but then you get used to jj (or jk) which might not be available on other vi modes (shells vi modes, gdb, glide browser ?) and it's overall quite nice to quickly escape any situation by having the key be closer.
Ctrl + [ would be acceptable if it wasn't, imo, the most important function of the editor.
I've yet to come across something with vim bindings that lacks a .vimrc where you can map 'jk'. Either way, switching back to ESC is as annoying as it is in the first place.
Not sure if this is bad form but i’ve always loved using jk for escape. It feels so natural to roll your index and middle fingers to get back to normal mode.
I agree, too, besides reminding myself to use numbers before movement commands there was really nothing that felt super hard about vim. It almost disappointed me, I always heard the jokes about not being able to quit it!
Yes but jk does not work in other contexts (shell vi modes at least for me) and it's actually to have Escape closer to home to quickly get out of a situation
To be fair I mostly use `/` + (n/N) + Enter with `incsearch` on (by default in nvim), I feel it's really the superior way to move around and it has deprecated a lot of my vim-fu.
In the same way, apart from occasinal `ciw` (or other text-objects), I do most of my edits with `:s/old/new`. I don't even use a complicated regex as sometimes it's just easier to write one or two simpler ones. It's just faster to not have to go to a specific location before you make an edit.
Because Ctrl+C for the most important function of you editor kinda sucks ? I mean you can get used to it, but you can get used to anything. Maybe we can have nice things ?
From the emacs perspective, it's barely even a learning curve. If you want to use the default keybinds it takes maybe a day to get used to them (probably less on mac since it uses some of them by default already) and GNU emacs has a very nice CUA mode. Hell, if for some reason you like vi keybinds and don't use vi and don't want to use vi, emacs has a pretty good vi mode
You know that CTRL + [ functions same as ESC right? Sr. dev at my job told me about this a year ago and it made vim SIGNIFICANTLY more comfortable to use day to day.
It's about the ascii code and terminal code. (Almost?) Every non-printing character can be entered with Ctrl+<some keyboard key>. With Control pressed, D is eot (end of transmission), G is bell, H is backspace, I is line feed (next line), L is form feed (new page), M is carriage return (start of line), Z is substitute, and [ is escape.
I is tab ('\x09' or '\t') and J is new line ('\x0a' or '\n'). These Ctrl combinations follow a predictable linear mapping to the control character section of the ASCII table. Basically Ctrl subtracts 0x40, so I is 0x49, Ctrl I is 0x09.
The big problem is stupid guides talking about modes instead of calling it a command interpreter, which it is. Modes are an irrelevant implementation detail.
I think it's the smoldering ruins of the OS vendor self interest collapsing in on itself.
There's not a single good universal UI. The best is the browser and it is reasonably successful but the sandbox makes it specifically unsuitable / high friction for doing things that need local access to files, network, etc. And it is ridiculously high overhead if you just want to run something simple. Then remote access is even more a debacle. Can I access an application running on my windows host from my Mac? can I forward that through a tunneled connection?
TUI is a simple, universal protocol that does what you need and is natively remote. Whatever I use locally will seamlessly work over an SSH connection.
And it's a big middle finger to the OS vendors who thought locking everyone in by making everything incompatible or ecosystem specific was a winning strategy.
The failure of the modern absurd GUI environment (Windows 11 is a GREAT example) is why I keep coming back to something like a minimalist xfce4 desktop environment. There really isn't a need for all the absurdity.
I wish TUIs weren't back. I'll take a web interface over a TUI any day. No installing fonts that are too clever, no tweaking my terminal config to get it to display right, no guessing the navigation shortcuts that person thought was best, real text editing with OS standard text navigation, better integration with my password manager, text expander, etc...
I live on the CLI, I have one a hotkey away, but please, technology has advanced significantly since the terminal was the only option, and we have far better options for building UIs now.
Web interfaces aren't any better. They're designed to for aesthetics and not functionality. Not to mention the fact that they all have their own UI idioms that you have to pick up on.
I really don't get terminal UIs that try to rebuild GUI-like functionality. Don't we think that computer interfaces should get better? We're not limited to a grid of characters to pretend to draw lines and shapes with anymore. You can't even display an image in a terminal without a non-standard terminal like Kitty or iTerm.
It's just a shame that we don't have a great cross-platform, streamed, UI system. The web is great in it's own ways, but clearly something could be a lot better for this purpose. Flutter's ok, but not on-demand enough and too married to Dart.
This is because of the failure of the modern GUI environment.
They want a GUI, but, instead, they have to resort to something like this. A GUI in a TUI.
They want something portable. They want something that can run remotely. They want something they can run more safely than having to expose a socket. They don't want to have to bring up an entire desktop.
Rootless windows are effectively dead. That leaves web interfaces (and all of their issues) or doing a TUI, where all you need is an SSH connection that everyone already has.
In the past you could slap something together with Tcl/Tk, and just launch the window over X Windows. That's not so easy today, and no one is running remote X anyway.
The LCD is SSH, and these are the only things that fit.
> That's not so easy today, and no one is running remote X anyway.
I was quite recently, but even then remote X is missing a really big usability piece: keeping a long-running application open on the host and periodically connecting to it from a remote node (concretely: connecting to my server from my laptop). VNC/RDP/etc all do this at the desktop level, but they're pretty mediocre experience-wise.
tmux gives me this for terminal applications without really any compromises. I run tmux for local terminals as well as remote terminals; the hotkeys are all deep muscle memory at this point. It just works.
Agreed. I dread GUI development, hence I never build GUIs. If there were a library for my language of choice that worked multi-platform and used native components then I’d be interested.
> That's not so easy today, and no one is running remote X anyway.
If you:
1. Have a low-latency connection to a decent machine, and
2. Are on a machine that's weak, or isn't yours, or that you don't fully control (e.g. employer forces you to run Windows)
> You can't even display an image in a terminal without a non-standard terminal like Kitty or iTerm.
Sixels are supported by many terminals[0] (several of the terminals mentioned that do not support them are based on GNOME VTE for which support is in the works and, based on the bug tracker comments, it seems to be almost done).
This includes xterm which is probably the most "standard terminal" on X11 you can get.
> really don't get terminal UIs that try to rebuild GUI-like functionality.
Because it's easy to get things done for a TUI, but if I create a proper GUI, my codebase is suddenly more complex. And it's not like there's a solid, reliable GUI toolkit that I can use, they're all riddled with different bugs and caveats.
> Flutter's ok
If you ignore the absolute nightmare that is building applications in Flutter. Even Flutter itself isn't really designed to be compiled by anyone (although, in practice, your distro will shield you from this issue).
My motivation is avoiding all the piles and piles of extra software dependencies that X and/or Wayland bring in.
In addition (but might only be relevant in my niche platform) is that Wayland is buggy and X is deprecated and unmaintained making making the GUI work there a constant struggle.
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.
This will run on Windows, Linux, MacOS, and Tcl's starkit/starpack system makes it easy to generate a single executable file for each OS that can just be copied over and run without any installation needed.
What I mean is that on Windows you can just ship an 100kb .exe and forget about it and it's still going to work 20 years later.
On Linux that doesn't happen. First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed. Second of all, even if you do ship the source code, you're going to be forced to maintain it. If you made an app in GTK 1 (which looks beautiful, by the way, compared to modern GTK), people won't be able to just install it because GTK 1 is so old that it's no longer in the repositories.
An app made in Java 8 runs in the modern VM. An app made for Windows 95 still runs on modern Windows.
It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
I'm not defending this but there was (or has been) enough political motivation and intentionality in GNU/Linux systems to make binary compatibility a hassle. People actually made decisions against backwards compatible APIs, intending to cause issues and forcing open-sourcing.
Binary compatibility means closed source has a chance to grow in an ecosystem. It requires "responsible" developers to put more effort into designing APIs and keeping them alive. It adds complexity that requires a more stable set of long-term developers; in contrast, the constant churn in FOSS requires lower barriers for contributions. With stable APIs/ABIs you have to live with decade-long mistakes. You cannot "just fix it" in a next major bump.
> First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed.
That's so very not true.
Most Linux distros allows for custom repositories. So you can just setup the build infrastructure on your side and then have the users include your repos on their side. No need to open source code and users have painless update notifications.
> It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
Lots of users have never seen the source code of their software, they just get the binary package. The pressure you're talking about is imaginary.
This is downright misinformation. There are no 100kb Windows programs that work for 20 years. Every single program on Windows ships half of the system libraries again, just for use by itself. Microsoft couldn't be bothered to version their libc at the beginning ffs.
WINE is often somewhat jokingly called a more stable platform for Windows programs than Windows is but there's truth there.
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
The article (as I read it) says that Google gave up on the new operating system (where Flutter would have been the default UI toolkit).
I’m not sure if Google actually already gave up on Fuchsia, I’d be surprised if the work actually stopped, but it’s clear now that it will not be a panacea and if it will ever get released and gets some traction, it’s still like a decade away from becoming a major OS.
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.
Their GUI system (GPUI) is not very mature for use outside of Zed. GPUI is basically a UI framework in the truest sense: a framework for building UI... frameworks/components. It has core functionality for async execution, an ECS for grabbing shared resources, and a div.
It's basically like building a website with div and basic CSS.
Up until sometime late 2025 GPUI wasn't even on crates.io, and it seems like the GPUI-component ecosystem still promotes using git deps. It was also in "read the code for docs" state for a very long time
It's been a while since I've used it, but there were weird things missing too like the Scollbar was located in Zed's UI component crates instead of core GPUI. Arbitrary text selection also is not possible, which is something I really value about egui.
What I do not like on Zed or electron GUIs is lack of customization. Older IDEs using sdks like Swing, JWT, QT, GTK etc. allowed user to design its user interface using drag and drop. ie compare older IDEs like eclipse or idea and try to create layout which fills screen with information important for you. And then try to do the same with vscode or zed. I like functionality and speed of zed but UI customization is too limited for me. It might be design choice or sdk limit I am not sure.
Arcane build system. I mean, I guess it technically supports CMake these days, but I have never been able to get anyone else's Qt project to build without much gnashing of teeth.
Emulated native widgets try for pixel-perfect, but tend to feel wrong somehow.
> Gtk
Outside of a Linux/Gtk native environment, Gtk applications are awful. Take GIMP on macOS, for example: it's had window focus issues (export dialog getting lost behind the main application window) literally ever since Gtk on macOS dropped the XQuartz dependence. And that's the flagship application for the toolkit.
So, your critique of Gtk sounds convincing, but about Qt, you seem to be admitting they're offering a less-horrible way to build than how things used to be.
I looked at this: https://doc.qt.io/qt-6/cmake-get-started.html
... and I'll admit they seem to be hiding some nasty stuff under the hood. But it still seems workable. I guess the devil is in the details?
That's one word that should never been used in an design meeting. None of the GUI I've used has managed to do this right. Even Emacs and Firefox. The platform are totally different (and in the case of Linux/Unix, there's a lot of different HIG competing). So trying to be cross platform is a good illustration of the lesson in https://xkcd.com/927/
The best bet should be a core with the domain with a UI shell. And then you swap the shell according to the platform.
I want my applications to look consistent across platforms. Why would I want discord for example to look entirely different between MacOS and Linux? With the current state of things, once I use the app anywhere, I'll know where everything is on any platform.
Take a good look around and check how often people do really change computer platform. And you already have so many things that are different that the "same look" is just an excuse. Gnome, KDE, macOS, Windows does not have the same UX in their file explorer which is a basic utility that everyone has to use. Same with connecting to a WiFi and creating a new user account.
So why would you want Discord to be consistent, when you're mostly using the same desktop (or switch between at most two) for hours.
The thing is when HIG were followed instead of everyone trying to create their "brand", everyone knows where the common actions were. You learned the platform and then can use any app. With the new trend, you would only have one computer, but any new app is a new puzzle to figure out.
I don't really have any issues working out how to use modern electron apps, they all follow very simple UX patterns, I find them much easier to use than the average native wxWidgets/qt app. Simple, consistent UI is less about the color scheme and border radius being consistent and about things being simple and well laid out on a higher level.
Two apps can have different CSS while being easy to understand because the core flows and ideas are the same. While many older native apps feel like junk draw UI with crap thrown everywhere and weird app specific quirks and patterns. Even if it all does use native inputs and windows.
Electron apps use the usual web 2.0 forced keyboard focus antipattern which breaks page up and page down scrolling, so they are difficult to use. Also blurry text rendering.
> The best bet should be a core with the domain with a UI shell. And then you swap the shell according to the platform.
I've rarely seen that turn out very well. Typically it works ok on whatever desktop main developers use, and not so much on the others. That means using multiple frameworks, witht their own idioms and quirks and having to repeat a lot of work. Unless your UI is very simple it is pretty expensive to maintain multiple separate versions of it.
The best way I’ve seen this implemented is having the domain be a library or a protocol/server. For a lot of saas, we already have people writing the mobile versions and the web version..
Yes. It’s more work than dumping Electron on users. Quality often is.
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.
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.
99% of LLM-adjacent software is webslop in a state of perpetually broken churn.
OpenCode for example has not yet figured out "maintain a log of all messages and send that log to the SSE endpoint in the same order to get the next response" and has regular prompt cache misses even with context pruning disabled
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
Impressively many dependencies? I estimate about 75-125 in the dependency tree, including multiple versions of the same package. Now compare to something written in e.g. C: such a program might have 2 dependencies: libcurl and ncurses.
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.
For the record: I have a terminal open at all times, my life is automated trough Bash scripts and I am a VIM / TMUX user.
With that background, most TUIs are really two steps back compared to a decent GUI. (Wild west navigation/hotekeys, broken copy and paste, lack of integration with the environment, just to name a few.)
The core of the problem is IMHO, that we really lack a decent cross platform GUI platform, which is really integrated into a programming language or part of the standard library.
Outside of Swing (which lacks access to a native browser element), we have Tk (no browser component, no drag'n'drop, at least from Tkinter), wxWidgets (seems that the community is very small and especially its bindings needed to be resurrected at least once), Qt with the ever looming possibility that it will get deshittified to make more money (... and no, KDE is not that important and I doubt the KDE community could take care of a fork long term).
Which leaves us with Electron or the other variants of 'browser component + JavaScript/CSS and callbacks to a local server, which is a really bad programming model (ignoring the memory/runtime overhead for even trivial applications).
The problem is, to build a decent cross platform gui toolkit, one needs a lot of funding and a lot of people (usability, accessibility, design, documentation, testing...). The open source community didn't manage to pull this off (GTK is by now for all practical purposes Linux only) and there is no modern contender for Qt or Swing (with their own problems).
TUIs are no solution to the core problem (and it would be absolutely possible to have a GUI toolkit with a TUI renderer for perhaps 80% of GUI needs), but I understand every developer who chooses TUIs for cross platform UIs given the alternatives.
> which is really integrated into a programming language or part of the standard library.
Not a programming language, but the programming language: C. The toolkit needs to be available as a C API because that lets it a) provide stable API and ABI and b) provide bindings for multiple other languages without having to jump through hoops, especially for other compiled languages (binding Qt to Python might be easy, but bindings to something like, e.g. Free Pascal requires an intermediate C++ library that exposes a C API that itself can be used from Free Pascal - and applications need to distribute it that library too).
Unfortunately the vast majority of GUI toolkits are not writtne in C but in C++ or some other language that makes using them from anything than the developers' favorite language a pain. And really the only mainstream that is written in C is GTK which has a complete disregard for proper backwards compatibility.
(you may think that a library only needs to expose a C API but it can be written in any language, however for something that doesn't have any widespread availability, you may want to link to it statically - however that can be an issue with anything outside C/C++ - as an example i recently tried to make a FLTK backend[0] for Lazarus since FLTK is a C++ library that the devs encourage to link it statically and it would allow creating GUI programs that are self-contained binaries... but statically linking a C++ library -for which i had to first make a C wrapper- in a non-C/C++ turns out to be a PITA under Linux if you are not g++ as that does passes a bunch of magic flags to the linker and impossible under Windows - or at least msys2, so i gave up).
I like, that you also added backwards compatibility and ABI stability, two very important and valid points. There is to this day the joke, that the best way to write a binary GUI app for Linux is to target the Win32 API and run it via Wine, if you care for a stable platform. ;-)
I think you are right and completely agree with most of your points.
> wxWidgets (seems that the community is very small and especially its bindings needed to be resurrected at least once)
Which is a damn shame because they are very close to native appearances on both macOS and Windows and are much easier to program than anything Qt. I think it’s the solution I prefer for multi platform GUIs, both as a user and as an occasional programmer.
> Electron or the other variants of 'browser component + JavaScript/CSS and callbacks to a local server
On the other hand, I absolutely hate this as a user. I would lose features and go back to the command line rather than having to deal with this. Everything is wrong in these applications, they don’t support standard keyboard shortcuts, they look weird and out of place and lag where you least expect it.
> TUIs are no solution to the core problem (and it would be absolutely possible to have a GUI toolkit with a TUI renderer for perhaps 80% of GUI needs)
There are a couple of TUI framework that are almost there already. I like the fact that they are useable without fuss over ssh and stuff but I think they are solving the wrong problem. I would rather use something like tmux but that sucks less for the windowing and persistence bits and get more focused and composable CLI. Make a simple REPL with readline so it has a standard and expected behaviour instead of trying to make everything look or behave like an IDE.
OTOH, I really like how this is driving improvement in terminal emulators.
Thank you very much, and I also agree with your points: Electron Apps simply never feel right, even if I work within them all day (VS Code for example).
I also agree, wxWidgets is quite great, although I have to also agree with the comment above, that C++ for a GUI library is just a PITA when used from any other language. AFAIK the consumers from wxWidget (wxPython, wxErlang?, ...) are using a C wrapper around the C++ wrapper to use it.
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.
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.
It's nuts that software developers are allowed to design user interfaces at all. They're incapable of making a user interface that isn't text. It's like if plumbers designed houses, they'd make all the floors slope downward, because that's the easiest way for pipes to run.
Oh we need multiple windows we can move around/resize? Let's make them text windows. We want people to be able to quickly select options? Yeah make those text boxes. We want to quickly compose documents with some kinda style/formatting? Yeah they'll need to write more text to format it (but let's not make any apps to easily view the text in formatted mode).
On the opposite end of the spectrum, you have material and (to some extent) adwaita which look pretty but are absolutely useless for anything more complex than app style development or maybe a file manager
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!
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.
Qt's license really isn't hard to figure out. If it's free software, you use the free software license. If it's propietary/commercial, you use the propietary license.
You can also use most of the core components (labels, buttons, grid views, image and media players) with LGPL in commercial apps. Only the more complex and more value-adding components like charts are GPL.
There is only so much rounding of borders you can do in the terminal! On a 16” MacBook, you can’t have Activity Monitor take up less than about 2/5 of the width of the screen! There is so much padding around every single element.
I don’t need pretty buttons, I need usability and readability. Without having a 50” display!
Somewhere along the way everything got dumbed down and all the info removed. It’s some condescending ‘so dumb ppl can take it in’ marketing bs I hear from time to time. And it sucks! I also doubt it’s true. Fashion be fashion.
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.
This nails it. The fact that the app interface looks exactly the same whether it's running locally or in an SSH session means I don't have to learn it twice. And while some GUI apps (VS Code for example) can be run remotely and still look the same, it takes a certain amount of ceremony to set that up. And worse, that ceremony has to be done for each app and is different for each app.
Running TUI apps over SSH isn't ceremony-less either — you have to set up SSH keys and copy your public key over into the remote end's authorized_keys file — but it's ceremony that you would have already had to do anyway to get access to the remote computer in the first place. And once that ceremony is done, you can now run any TUI (that the remote computer has installed) remotely without any more ceremony.
Power users have always preferred the command-line, since expressing what you want to do as a programming language is of course much more powerful and productive than clicking menus.
To avoid context-switching from the command-line, many essential UIs were made text-only. Another route would have been to integrate the command-line within graphical applications, but few did it -- the main example that comes to mind is Jupyter.
Blender is a 3D modelling program with a scripting language in it (Python). When you open the scripting pane, it's a command line. But it doesn't try to force the whole program to be in the command line, only the part where the command line is actually useful.
TUIs are much closer to GUIs than CLIs. As a CLI enjoyer, I was resigned to the small win that at least many people distinguish TUI and CLI now but then I saw your comment.
There are quite a few GUIs that can be navigated with keyboard, e.g. menu bars can usually be activated with alt or win and single key presses
Because we are all working on remote machines these days. Laptops have become thin clients that run fat local electron browsers that connect to the actual computer via http / ssh.
We made our machines 100x faster and instead of running compute locally we just made 100x slower client software.
> 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 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.
The culprit is using web technologies where they don't belong, which Electron is also guilty of. Claude Code is 400k lines of JavaScript for a TUI where a sane implementation in C would be two orders of magnitude less code.
Except most of the TUIs I’m seeing are god awful with horrible input latency because they’ve reimplemented everything from scratch in python or whatever. Multiple hundreds of ms per keystroke: it sucks.
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.
Companies make UI/UX to prioritise first 30 minutes of the experience, to keep user using it long enough that they stick with it. Not the 8h/day work the UI will get when a tool become pillar of your work.
Sometimes I swear that people are just making up acronyms here to troll people.
I assume you mean "orders of magnitude" and not "out of memory". I have never seen the former used as an acronym before, let alone without some kind of contextual clue. (In typical Baader-Meinhof fashion, I'm sure I'll see it again in the next 24 hours...)
I have just combined those together. I use astronvim as main editor but when I need IDE I switch to Idea. I use ideavim with configuration as close as possible to astronvim. So text editing is the same for me in both programs. Modal editors are still great and they can do a lot of work that looks like magic for AI era trained developers.
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.
Window managers are more flexible than multiplexers, but I also think there's a higher floor of effort juggling multiple separate GUI programs than going between tabs and panes in a terminal emulator.
Multi-monitor terminal juggling also probably loses out to GUIs, though for me it's usually IDE or Browser on one and multiplexer on the other. One big zellij session connected to multiple terminal emulators is probably the best way I could think to handle that.
> a higher floor of effort juggling multiple separate GUI programs than going between tabs and panes in a terminal emulator.
Depends very much on your window manager. Tiling window managers such as Hyprland let you open multiple windows and it will automatically arrange them side-by-side. Want one of them to be 60% and the other 40%? No problem, there's a keyboard shortcut (configurable) for that. Have four windows open in a grid arrangement and want to switch between them? Just slide the mouse, no clicking needed so the movement can be as rough and imprecise as you want, OR if you don't want to take your hands off the keyboard then SUPER+arrow keys (also configurable) will move the focus to the next window in that direction. (And if you are in focus-follows-mouse mode then it also moves your mouse cursor to be in the middle of the focused window, so you won't lose window focus by accidentally bumping your mouse and moving it one pixel). Keyboard shortcuts for maximizing and un-maximizing windows, for throwing them onto other workspaces and switching between workspaces...
I throw windows around my screen all the time, and rarely take my hands off the keyboard to do it. It's the fastest, most flow-like window manager experience I've found yet.
How does the browser interact with the os? A tui exe has direct access. With “only html” now we need a server of some kind. How is multiple layers and running processes superior to a thin terminal based wrapper around the relevant io?
That said, obviously it depends on the use case. I’m not going to make a tui to interact with locations on a map - a web app makes a lot of sense in that case. But something like lazydocker makes sense more sense as a light terminal based program
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.
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.
Projects like opencode are making the distinction between GUI and TUI almost meaningless. And that "only" downside is a massive, deal-breaking one. At this point I only have a browser besides the terminal, and I can see that going away soon for the most part thanks to LLMs.
But GUIs are hard to built - mainly because of tech debts around all three major platforms. But nontheless displaying graphics is harder than outputting control chars.
You could whip up decently usable UI in Delphi far quicker than similar one in any TUI framework.
The problem is that world went away from that and into HTML/CSS/JS/DOM mess that makes simple UI things hard and complex UI things slow and/or hard, on top of the bloat.
VB6 could have you roll a GUI interface in minutes, so even trivial tasks could have a GUI.
The tools for CDE on Unices were arguably even better but CDE never really got any momentum.
That it’s tough to put together a GUI now is definitely a regression and Microsoft shooting themselves in the feet regularly over the last 25 years is squarely to blame.
It's an aspect I've wondered about, constraints do make you consider what's essential. For example in btop (screenshot in the article) the graphs are rendered with dots at low resolution, if there was another version where those graphs were full resolution is it telling you meaningfully more?
Since the dots in btop's rendering are using the Braille characters, meaning you get six dots in the space that would be taken up by one alphanumeric character, the resolution on those dots is surprisingly high. A maximized terminal on my screen is size 316x86, so that's 316×2 x 86×3 = 632x258 of "Braille dot resolution" (a term I just made up) available for the graphs. Sure, that's lower than the 2560x1600 pixel resolution of my screen, but you're entirely right to ask "Does that really matter?" The graph would be smoother with about 4x more horizontal pixels and 6x more vertical pixels to work with, but I doubt I would glean any more information at first glance.
I’ve been running Claude with --dangerously-skip-permissions. It’s so nice that I’m not sure I can go back. Pressing continue 15 times is surprisingly heavy, but you don’t notice till you don’t have to do it anymore.
Try an external sandboxing tool. When you need to adjust the sandbox, close the agent, launch it with the new params, and resume the session. It doesn't take long to arrive at a stable configuration; for me it's mostly about rw access to the CWD, read access to other local repos, and access to Nix. Other than that I can just use YOLO modes and not sweat it.
I briefly evaluated a bunch (had an LLM make a list of those that satisfied some basic criteria, then visited READMEs and websites) and chose nono. No regrets: https://nono.sh/
Hey, thanks for the tip! I'll also give those a try.
Even if I end up liking virt-free like nono stuff for agents, I am trying to explore and learn about microVM options lately for other development purposes as well. This is a serendipitous recommendation for me. :D
I thought that that was the case for me, but then I tried using Claude Code through the desktop app last week and it was so bad. Slow, glitchy... I went back to the TUI in no time.
Having worked with development since the early 2000s, I think its great that development has become more accessible and I dont particularly like that the old guard tries to gate-keep the idea of "being a developer". Being an engineer I feel requires more credentials, it always has. But if you feel like you're a developer, all the more power to you!
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.
TUIs suck and the only reason they are seeing a re-surgency of relevance is because everything else sucks more along one or more critical metrics. Given the truly incomprehensible amount of CPU and GPU power we have available, this is truly a blight on our industry.
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.
I'm biased towards CLI and reign of LLMs means we're all Unix/text (for) now. So IMO there are many reasons, but chiefly amongst them is UI/HCI design leader Apple throwing out their/industry's interaction design best practices over the last 10+ years.
Embracing constraints and "how it works" used to be at the core of their software ethos.
One thing I like about TUIs is that they can usually be completely operated from the keyboard. Most GUI apps have flows that you need the mouse for, and they’re slow if have to do that often.
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.
> if you make a slightly mistake in coding a full screen app, you get screen corruption.
HOW? The TUI library should handle everything for you. So HOW do... Wait. Did Claude vibe-code up its own set of TUI routines instead of using a library?
The article spends a lot of time talking about how UIs “look” and how they all “look different”. That's not the important aspect to me.
For me what makes a software usable in the long run (after initial learn) is shortcuts and keyboard navigability. Old GUI frameworks had built-in features for this (app-wide shortcuts, underlined letters, etc.). The web has haphazardly copied one of them (“accesskey” attribute), but now this has been completely forgotten. None of the major websites have accesskeys, even for the most frequently used element like the search bar. There are no shortcuts for frequently used functions such as “like”, “reply”, what have you. It's like developers have universally forgotten that the keyboard exists and what it can do.
It doesn't really make sense to me. I've been using Emacs and Vim for decades, and have been using Claude Code for months, but I moved to Codex GUI and the VSCode Claude Code plugin eventually. The biggest problem is that monospaced fonts are not really the best for reading, and with coding agents, people should be reading text most of the time.
The current implementation isn't command-line, but a re-implemented GUI in disguise, awkward and even more buggy. Why should I use that over a GUI? I would prefer Electron over those TUI unless I have to SSH.
I'm not surprised at all, if I was to choose from TUI or browser-gui (electron, react, react-native, anything similar) i'd always choose TUI. Good gui design died a long ago. Almost every gui designer needs us to always look at some nonsense animations that serve zero purpose and just make you needlessly wait. There is no such thing as "essential" animation in GUI. And no, plain simple progress bar does not count as animation, but rotating "progress circle" does. GUIs got so unbelievably bloated, it used to be an advantage to have more pixels, as you could pack more information in useful way. Today? Nah. Look at signal (or signal-desktop), it's not even funny anymore. Dolphin used to be good file explorer. Today it's borderline usable, animated so much so that i have to maintain own patched version. One just cannot hide from this, mostly because devs do not understand (or want to acknowledge) need for this stuff to be configurable (instead they more likely focus on stuff no one actually needs. again looking at you, signal.). Or stuff like libadwaita that is likely one of the most arrogant take on gui library ever.
They've been back and we're all taking them further than ever before!
For the past few weeks I've been wrapping up Booba [1], which is developer tooling to combine BubbleTea and Ghostty in WASM deployments (using ghostty-web).
It provides for some interesting deployment patterns both locally, over network, and embedded in a web page. It's intended to be very easy to adopt; at the simplest, one just changes `tea.NewProgram` to `booba.NewProgram`.
I used Booba to make a demo page [2] for our NTCharts TUI library published to GitHub Pages. The repo READMEs have GIFs... this page is all embedded WASM.
There's also new Kitty-Graphics-supported widgets in there (picture, chartpicture); I updated Booba and Ghostty-Web to support it. Still getting the kinks out.
I do like CLI tools and 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.
Those apps you mentioned are not your typical modern GTK4/libadwaita apps, so naturally you can theme them. It's the GTK4 apps - and ones which use libadwaita specifically - that cause grief.
- Firefox: Uses its own custom rendering engine but interfaces with GTK3. It respects standard GTK3 themes.
- Thunar: Uses GTK3
- GIMP: Since v3.0, they now use GTK3
- LibreOffice: Uses its own visual framework (VCL) but has a GTK3 plugin to draw its window frame and menus, and it also respects the system theme.
None of these use libadwaita, let alone GTK4, so they're not good examples unfortunately.
They're some of the most popular GTK apps available. They seems like a good example to me.
The themes I'm using are compatible with GTK4 apps too.
I use niri which suggests installing xdg-desktop-portal-gnome which comes with Nautilus which is a GTK4 app. It's perfectly themed just like the GTK3 apps.
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.
I think well made GUI will always be superior to TUI. And have all the same possibilities and more. But it is also very sad that now decades into this computing thing we do not have any accepted good ways to make GUIs. Or at least widespread enough ways.
Two advantages:
- Deliver apps over remote
- Superfast keyboard interaction (forced)
One big disadvantages:
- Limited graphics and advanced UI component support
I would say the optimal UI is a Keyboard driven normal Desktop app. An app that can take full advantage of graphics elements of a desktop app but is lightning fast to interact with thanks to that it's keyboard driven. Very few people build apps like that though. Sure there are keyboard hints in many apps but they are usually not 100% guaranteed to cover all cases and are sometimes an afterthought.
Am I missing something: "[TUIs are] easy to automate". What am I not seeing or know about? I had to go crazy mad routes of automating TUIs with `tmux` just to get to some repeatable process.
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.
I kind of wish we had HTML but for GUI. Imagine if you had a "gui" flag in terminfo and you could send an escape sequence on stdout after which you could send out screen updates as a stripped down form of HTML on stdout and receive events on stdin. I mean something that can describe the simplest bog standard Windows 95 application with a menu bar, side bar, dialogs, buttons, and proportional text. Otherwise we could offer a GUI for applications over SSH by having the terminal open a local TCP socket connected to stdin/out and launch the user's browser, implementing the most barebones CGI.
HTML does describe GUIs though. Browsers are engines that turn a text description of a GUI into a rendered GUI.
I get your point, it does feel like there's something different, but I'd suggest that there is no black and white line, instead there's a spectrum, with fully native local UI at one end and fully declarative remote GUI at the other end. HTML and the web exist somewhere towards the latter.
There have been many attempts at points all the way along that line though, and every point comes with trade-offs. Performance degrades, OS-native components are eschewed, programming gets higher level, etc.
We need lightweight HTML/JavaScript applications that aren't an entire web browser. You already have a web browser installed, you shouldn't need yet another copy of Chromium to run some HTML/JS files. Because browser makers cripple HTML files run from your own computer (can't fetch any files, even from the same directory), you are forced to start a web server just to run HTML and JS files from your own hard drive.
If you have python installed, you can start a web server with a couple lines of shell script. Is there any really good truly lightweight webserver? (Something under 256KB)
I worked in a lot of places where mainframe applications survived along with their more moder replacement for years, because experienced users were orders of magnitude more efficient using old mainframe TUIs than the clunky and slow web interfaces that replaced them.
Even in the PC world, the move from DOS based TUI programs to windows GUI in applications like POS was not without some user trauma and insatisfaction.
I think Midnight Commander is still the most advanced TUI there is. It has so many hidden capabilities that you may not even know about. You can be connected over ssh to another computer, while browsing the inside of a compressed zip file and previewing the content of the file inside of it . If you enable lynx motion and case insensitive - you are navigating across folders so much faster than just trying to "cd" and "ls"... It's impressive that this category of file managers has worked the same way for more than 40 years - the same shortcuts, etc.
I totally agree with the author that Windows GUIs and MacOS GUIs are getting worse with every iteration. For my own side project I used ImGUI and it's working great for my purpose.
It's by far not as beautiful rendered as the native OS layers, but easy to navigate and a good foundation for cross platform GUI development. And I got it even approved for the MacOS app store. Here's my write up: https://marchildmann.com/blog/imgui-mac-app-store/
I'm pretty sure dismissing flutter is ignoring reality. It, and more so dart, are not popular on HN, but it definitely is a popular and still in development truly cross platform framework.
I saw that - and it doesn't seem to fit the bill. First, Dart is a language, not a GUI toolkit; and Flutter seems to be focused on Dart. It also seems to be opinionated in other ways in the introduction, rather than exemplifying its flexibility and adaptability to _your_ platform, programming language etc. Most importantly, it seems it will get you to produce apps whose UI fits a mobile phone rather than a desktop. I also get the sense that Google has strong control over this project.
Maybe I'm mis-perceiving - but that's the impression the flutter.dev site gives people.
Dart is the language flutter (the gui toolkit) is written in.
I've no idea what you mean regarding: "rather than exemplifying its flexibility and adaptability to _your_ platform, programming language etc".
It can produced mobile, web, or desktop apps from the same codebase... Dart and flutter are open source projects supported by Google, like android and go lang.
Seems like you're looking for excuses not to use dart/flutter. That's fine but you could just say you don't want to use them.
> Dart is the language flutter (the gui toolkit) is written in.
Well, that's already a strong barrier to its use. When creating a GUI for an app, the toolkit must offer bindings for the language you're using, it's not you that needs to learn a bespoke language just to use the toolkit.
> It can produced mobile, web, or desktop apps from the same codebase...
That's the thing - not really. It seems it can produce a web or a mobile app while will _run_ on the desktop. But mobile and web apps do _not_ work as desktop apps, nor the other way around; the whole UI/UX language is different... even if some companies try to foist mobile apps onto desktop users.
Obviously if you are unwilling to learn a new language then yes flutter is not going to do it for you. Flutter is Dart's gui framework and it's excellent. Dart however is itself a lovely language and extremely easy to pick up if you have any knowledge in programming. Much easier than learning the flutter framework to be honest.
> That's the thing - not really.
If you were to spend some time learning dart and flutter you'd know this to be false. But I'm not here to change you mind as you've already made it.
A ton of industry applications are written in flutter. Point of sale systems, automotive interfaces, bespoke industry applications within offices, etc.
The install base would be huge, and it's a solid cross-platform option.
I love TUIs because so much of my dev career was ssh/mosh/tmux to remote servers and working where the fast network bandwidth and computational crunch lived.
I was vibe coding a layer on top of textual last week that allows me to plug in both interactive and information display Python functions into a TUI grid. Really simple stuff, with textual doing the heavy lifting.
One of my first jobs was working on Telephony User Interfaces (TUIs). Everytime I see the term TUI I can't help but think of that.
For people who don't know this version of TUI, it's the ole, "Press 1 for X, Press 2 for Y" kind of interfaces that you use over a phone. Think voicemail text-to-speech and automated speech recognition.
> I do not necessarily argue for cross-platform support, but having one such solution would help reduce the electron and TUI dependency.
I think this is the primary reason. I feel like whether or not there are good native libraries things were bound to converge into cross-platform preferencing since it's cheaper to produce and maintain.
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 only reason CLIs and TUIs "came back" is because we're still in the early stages of this paradigm, things are moving fast and building a strong GUI UX takes just as much time as building out the backend functionality. So CLI and TUIs are used because they save time, skips the need for building a time consuming GUI. Also building UI is hard.
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."
I make some things GUIs and some things TUIs. The TUIs are easier to work with Claude Code and Codex. We can co-work on many things together because the LLM harness reads TUIs very fast. You can do it with GUIs but that's much slower, and maintaining two separate interfaces into these things isn't worth the trouble.
I spend all day in a terminal multiplexer (zellij) with neovim and other splits. Using things like k9s / btop / lazygit / lazydocker helm / stern / whatever that systemd TUI I saw in here and started and will check out later just keeps me focused in one window, and that’s pretty cool
I think most people are missing the forest for the trees.
TUIs are popular because once you use a piece of software that doesn't have a poorly-written GUI library full of animations bogging it down, you don't want to go back.
It's hard to make a TUI that isn't snappy, no matter how much useless eye-candy it has.
I have a theory that we’re moving back to TUIs because they’re responsive and will be compatible with wearables. It’s easy to overlay just text using TUI’s onto a visual portal.
> Reviewing code is important, but it's only 50% of the learning process, at best
I don't know about everyone else, but the code I reviewed as a Junior was high quality code I was expected to learn from. That's entirely different from doing code review on whatever CC outputs.
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
The bottom of the post contains an interesting suggestion, for us software developers to read one of three 'basics' books on UI: "Nielsen, Norman or Johnson".
Can someone who is more knowledgeable about these help compare and contrast these three texts a bit?
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 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.
They are back because modern languages (Rust, Go) have made it pretty straight forward to build them. Ratatui and such allow you to write a TUI really quickly without needing to deal with VT100 arcana.
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 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.
In any course, if the UI does not make any sense, the project should be failed.
Failing projects over bad UI teaches fear, not design. Good interfaces come from iteration and feedback - which is exactly what user-centered design is about
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.
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.
It's well known how it works. If web browser is efficient, it just invites webdevs to spend all the extra resources until it's slow again. Wait for AI assisted mouse cursor.
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.
And for those of us devs, they never really went anywhere. vim was the most popular editor on HN 15, 10 years ago, still very popular 5 years ago, still popular today.. and that's just an editor, all the other tools like top and its descendents never went away.. I'll believe "TUIs are back" or in some kind of uprise when I notice my non-developer friends and family using them for anything. The most dominant UI today is the mobile app, that's not changing. Limited to professional use (i.e. doing work for someone) and not all use, TUIs aren't touching either web apps or native GUIs either.
Many "non-technical" folks who have interacted with virtual 3270 terminals for all sorts of mission critical tasks would disagree sharply with that assessment. And those are essentially TUIs.
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.
Yes. Developers are conditioned to expect the only convenient answer is a TUI (actually, a CLI; TUIs are show-off projects most of the time) and, if you really want to go all out, Electron. That's not the case anymore.
In the "before times" an API and web UI that double times as native via Electron was the biggest bang for your buck.
CLI would be a hacker's side project, TUI would be them showing off more. Native would require hiring a team of specialists which is a total non-starter.
In the "after times" API and CLI are getting more love rebranded as MCP and tools.
To the parent topic, I suspect "build a TUI around my CLI" is a slam dunk for an LLM text in / text out machine which is why there is a resurgence of these too.
Hopefully that is the gateway drug to "build a SwiftUI around this", and an antidote to doing everything in Electron.
The guidelines are pretty clear that basically all of this comment is not ok, and that this kind of comment is net negative for the quality of the site.
> Be kind. Don't be snarky.
> Edit out swipes.
> When disagreeing, please reply to the argument instead of calling names.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
It seems pretty clear that saying most TUI projects are show-off projects does not mean all TUI projects are show-off projects.
I don't know why you're so aggressively attacking the idea of people making projects to show off.
The claim isn't that zero people use them, or that all TUI projects are made to show off. But most of the TUIs you see land on HN are things somebody made to play around with a technology / scratch a momentary itch.
No shade on those people; making a project that brings the author joy is an awesome reason to make something, and sharing it with folks here is one of the better things about this site. But the TUIs you see here are, by and large, not aiming for (and not going to get) broad adoption.
Every time I read a comment like this, I flash to the episode of the Office where Michael steals one of Dwight's clients while Dwight is on the phone with him in the car. He pitches the client, and Dwight screams into his phone "ARE YOU SAYING YOU INVENTED PAPER?!"
No, friend-o, I'm not saying htop and emacs are show-off projects --- though everyone I know who uses Emacs (myself included) uses graphical emacs.
My point is that most developer tooling is CLI, not TUI; most developer tools are shop jigs, not packaged tools. Though most of the packaged tools: also CLIs!
All of them can very quickly be made into native UIs, though.
You'll get further on HN not calling people "very dishonest".
LLM reimplementations for parallel versions are going to be fun to maintain, eepecially when AI market maturity ends the era of AI firms subsidizing coding tools as part of their marketshare competition efforts.
If you think it’s all a house of cards, obviously none of my arguments hold. I’m not going to hedge that every time I write anything that intersects with AI though.
> If you think it’s all a house of cards, obviously none of my arguments hold.
I don't think its all a house of cards; LLMs are real technology with real utility, in coding and lots of other domains.
They are also massively and unsustainably subsidized for certain uses (and the increasing crackdowns on repurposing the subsidized services for other uses should make it clear to anyone that the subsidies are unsustainable, and that there is a very clear focus on owning certain markets before when the music stops motivating them.)
Sure, for small projects. Otherwise, you'd better have a solid plan in place for keeping your business logic in a common core, otherwise you'll just be writing N separate implementations where N = number of target platforms.
Even in a world of agents, less code = better code.
Sure, I hear this (with current models). But consider the UX complexity of a typical TUI. Even with a TUI framework, you end up with serious coding lifts just to get things that the all the current native UI frameworks give you for free.
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.
- You don't have to ship Wine with it, you can just make it a runtime/package dependency. Most distros have Wine in their repos anyways, so there's no need to bundle it. I don't see this conceptually being any different than shipping a Python app for instance.
- You can make Wine apps inherit the system theme, well, at least the colors. Although it will still look out of place, but it's not much different to the issues with running a Qt app in GNOME, or a GTK app in KDE. Wine in this case can be considered as just another UI toolkit that has the same problem that all UI toolkits have in Linux.
- Finally, the resource overhead of Wine is far, far lesser compared to Electron, which is a basically packing in a full-fledged browser.
CLI. Wtf is a TUI? LLMs say it has some to do with interactivity in a menu or something, but believe me, we had this all in the 80’s. Nothing new here, but the truth is the CLI is better faster and cheaper. Pick all three.
CLI is "run a command, get output, drop you back at your shell prompt". TUI is a full-screen interface inside the terminal which you stay inside of, no longer interacting with your shell.
Yes I agree, something like vi or GNU nano is a great example of a TUI. The meaning is drifting a bit but I think the distinction is useful: a CLI program is one that you can invoke from a Makefile.
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.
My terminal has not been ensh*ttified. I used the Internet for work, for knowledge, more than I use it for entertainment. One of the reasons I like TUIs.
Why am I back on the terminal and 40k lines deep in my own ai-workflow tui? Two reasons: 1) AI writes my dotfiles. It fucking rules. 2) charm bracelet tui ecosystem in go is ace and ai writes it well.
Because now we have a young generation nostalgic of their parents experience in the 1980-90's, and that includes the TUI experiences we were stuck with back in the day.
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.
ahh the classic - see one anecdote - then create a narrative that the world is changing.
if TUIs were truly back - as DHH would like you to believe - his money maker - Basecamp - would be available as a TUI, Salesforce, Workday, Bloomberg etc would be available as TUIs. Though Bloomberg is the closest to a TUI.
Yeah. I expected article to give much more thorough analysis and set of observations and trends. As far as the actual observation of popularity of TUI, the only relevant part is claude and codex. The rest is about his personal opinion of TUI (vs other UIs)
Nobody here (especially top comments) seems to mention this.
Developers often say that TUIs are better.
But this is largely a matter of taste. To be honest, outside the programmer class, how many groups of users actually like TUIs? Very few.
Linux is lighter, and these days even gaming through tools like Wine/Proton has improved a lot. So why do Windows and GUI-based systems still sell more and get used more widely? Because most people prefer wrapped UIs. They prefer interfaces that visually package the system for them.
Electron has real problems: memory usage, deployment bloat, and ecosystem fragmentation. But if you move too far toward TUI-first tools, your market target becomes much smaller.
So the real question is: why are TUIs coming back in the AI ecosystem?
My answer is: AI FOMO.
Seriously, why are AI-integrated IDEs like Cursor and Antigravity becoming popular? Even when AI chat is built into the IDE, the IDE often freezes or slows down. If you just open a terminal, it is much faster.
So yes, TUIs are attractive in AI workflows because they are fast, direct, remote-friendly, and easy to automate. But explaining their return only as a failure of GUI is too technical a view.
There is also a social and market reason: people want access to AI workflows as quickly as possible, even if the interface is not what ordinary users would normally prefer.
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.
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 older cmd.exe console
You are confusing cmd.exe with conhost.exe
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.
Yes, and in fact even Windows conhost hast supported ANSI escapes since 2016.
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.
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.
Ink is the Electron of text-based apps. I tried OpenCode out of curiosity, it routinely used hundreds of megabytes of memory.
I'll stick with Emacs as my TUI platform of choice, especially for tool-assisted development.
What a fascinating modern age we live in.
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.
>try making a DAW in it
The very early DAWs kind of had TUIs, to be fair. Things like the Fairlight CMI
https://adamstrange.itch.io/qasarbeach
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.
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.
What do you mean by "It's not automatable at all..."?
At a former job we had automated extraction of data from a 3270 terminal (several of them actually).
"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.
> try making a DAW in it...
It would in fact work pretty well for a tracker.
[dead]
I'm still motivated to adopt a TUI application in lieu of a pure CLI or GUI because of the ability to use it over SSH.
Why can't you use cli over ssh? I mean you could even do gui id you really wanted to.
Yeah, not sure why I included the CLI bit... of course they work well over SSH.
> 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.
This has surprisingly few valid use-cases.
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.
The web is way too heavy for simple applications. On Plan 9 devdraw text is a first class primitive - its a GUI built around displaying text.
And who said text isn't a useful medium? We are discussing how it is displayed which today is on bitmapped displays.
> The issue with GUI systems is that output != input.
Can you elaborate?
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.
[0] https://zed.dev/docs/remote-development [1] https://code.visualstudio.com/docs/remote/ssh
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?
Likely combination of both.
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.
TUIs reclaimed popularity long before Claude Code existed. Just look at the Charm ecosystem https://charm.land
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.
> What originally got me excited to build TUIs was the concept of delivering apps over the wire via SSH.
This echoes my main interest in TUIs. Otherwise, I greatly prefer a good desktop application.
The TUI version of ClaudeCode is not even that good compared even to the VSCode plugin.
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!!
How come?
Added benefit is that auth is much easier over SSH than it is over HTTP
> 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 function in a 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 Escape is used is a historical artifact that needs to be called out.
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 look up for more when you feel you're spending too much 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 Shift 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...)
I remap Caps Lock to Ctrl when held and to Esc when pressed - the best of both worlds when you live in Neovim. https://github.com/rvaiya/keyd works really well for me on Linux, but there is a similar software on MacOS.
Easy with https://karabiner-elements.pqrs.org on Mac.
and if you really need the SCREAMING, vim got you covered. Just type your word normally , select it in visual mode and type gU
why visual mode? gUiw
fellow Caps Lock to Ctrl remapper (and neovim) here...
I map it on all my computers, works well, if I end up in an environment where I don't have the mapping I just use Ctrl-[ or stretch.
When I end up helping other devs and use their non vim setups...now that really trips me up. Capitals everywhere, random hjkls ... I have to really slow myself down when using a "normal" editor.
Which is why I never went with CapsLock being both Ctrl and Escape depending of whether it's part of a key combo because it's whole setup. On the contrary, whenever I use someone else's machine I can quickly go in the settings, set the option and then set it off after I am done.
Ctrl-[ is accepted across Vim installs
When using Ctrl where caps lock ususally is, this can be a very comfortable "pinkies out" manuver.
On macOS, this is easy. For everything else, I use mechanical keyboards that all run QMK/VIA so I remap it at the hardware level.
If only keyboard makers would just always put escape there.
It should always be "hold for control" and "tap for esc".
Ctrl-C also works.
No, that's different: https://vi.stackexchange.com/a/20028
Works most of the time, the rest of the time you can just use `Ctrl-[`
Weirdly enough I actually like that Esc is so far away and it is not for efficiency but for ergonomics. It forces me to lift my hand up and reposition it away from the home row and back so I'm forced to move muscles that would otherwise just wait around and collect RSI points. I tend to use the arrow keys often as well for the same reason on the other hand (although I do still use hjkl quite a bit still)
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.
I was just thinking this today tweaking the layout on my lilypad58, a layout I don't love and kept arriving at, "I just want more modifiers". Using JIS is genius.
My JIS bottom row is currently:
<Meta> <Super> <Alt> <Control> <Space> <Control> <Alt> <Super> <Compose/Meta> <Greek>
I have left Control mapped to Meta, {,Mu}Henkan mapped to Control, Kana to right Alt, right Alt to Super, Menu to Compose/Meta (tap/hold) and right Control mapped to Greek.
I use keymapper[0] to do low-level remapping and tap/hold, and a custom XKB layout for the Greek modifier. I highly recommend this setup.
[0]: https://github.com/houmain/keymapper
Map to "jj" and call it a day since your finger is already on the home row
Also ctrl + [ is standard terminal/ascii for esc so that might be a bit more ergonomic than reaching for esc
Yes but then you get used to jj (or jk) which might not be available on other vi modes (shells vi modes, gdb, glide browser ?) and it's overall quite nice to quickly escape any situation by having the key be closer.
Ctrl + [ would be acceptable if it wasn't, imo, the most important function of the editor.
EDIT: My bad, you can do it with Glide apparently
I've yet to come across something with vim bindings that lacks a .vimrc where you can map 'jk'. Either way, switching back to ESC is as annoying as it is in the first place.
Claude's vim bindings don't support ESC mapping, unfortunately for muscle memory. https://github.com/anthropics/claude-code/issues/25306
Well I have given at least one example. Do you not use bash/zsh/fish/nushell vi modes ?
Do you not use web search to verify assumptions ?
I should have. I don't why I assumed the line editors couldn't handle two keys in a row.
"jk" is even faster (you get to "roll" your fingers)
And keeps you on the same line unless it was the last one, if you were already in normal mode.
If you’re on windows, powertoys is a set of first party customization utilities, one of which is a pretty nice keyboard remapper.
https://github.com/microsoft/PowerToys
Not sure if this is bad form but i’ve always loved using jk for escape. It feels so natural to roll your index and middle fingers to get back to normal mode.
I agree, too, besides reminding myself to use numbers before movement commands there was really nothing that felt super hard about vim. It almost disappointed me, I always heard the jokes about not being able to quit it!
Yes but jk does not work in other contexts (shell vi modes at least for me) and it's actually to have Escape closer to home to quickly get out of a situation
To be fair I mostly use `/` + (n/N) + Enter with `incsearch` on (by default in nvim), I feel it's really the superior way to move around and it has deprecated a lot of my vim-fu.
In the same way, apart from occasinal `ciw` (or other text-objects), I do most of my edits with `:s/old/new`. I don't even use a complicated regex as sometimes it's just easier to write one or two simpler ones. It's just faster to not have to go to a specific location before you make an edit.
It works in bash and zsh at least.
I stand corrected
> 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)
C-c isn't quite the same, alas, but C-[ is. (compare 5itest<esc> vs 5itest<C-c>)
Because Ctrl+C for the most important function of you editor kinda sucks ? I mean you can get used to it, but you can get used to anything. Maybe we can have nice things ?
Also just to be pedantic: https://stackoverflow.com/a/5036294/10469162
From the emacs perspective, it's barely even a learning curve. If you want to use the default keybinds it takes maybe a day to get used to them (probably less on mac since it uses some of them by default already) and GNU emacs has a very nice CUA mode. Hell, if for some reason you like vi keybinds and don't use vi and don't want to use vi, emacs has a pretty good vi mode
You know that CTRL + [ functions same as ESC right? Sr. dev at my job told me about this a year ago and it made vim SIGNIFICANTLY more comfortable to use day to day.
I’ve been using vim bindings for a decade and never knew this…
This is how I felt when I got told :D
It's about the ascii code and terminal code. (Almost?) Every non-printing character can be entered with Ctrl+<some keyboard key>. With Control pressed, D is eot (end of transmission), G is bell, H is backspace, I is line feed (next line), L is form feed (new page), M is carriage return (start of line), Z is substitute, and [ is escape.
I is tab ('\x09' or '\t') and J is new line ('\x0a' or '\n'). These Ctrl combinations follow a predictable linear mapping to the control character section of the ASCII table. Basically Ctrl subtracts 0x40, so I is 0x49, Ctrl I is 0x09.
TIL: Ctrl subtracts 40.
(28 year emacs user)
on a linux box try `man ascii`
There are lots of man pages. This one doesn't mention Ctrl being minus 40. Not sure what the point is.
> I don't see where the learning curve is
Right here:
> modal editor
The big problem is stupid guides talking about modes instead of calling it a command interpreter, which it is. Modes are an irrelevant implementation detail.
[dead]
I think it's the smoldering ruins of the OS vendor self interest collapsing in on itself.
There's not a single good universal UI. The best is the browser and it is reasonably successful but the sandbox makes it specifically unsuitable / high friction for doing things that need local access to files, network, etc. And it is ridiculously high overhead if you just want to run something simple. Then remote access is even more a debacle. Can I access an application running on my windows host from my Mac? can I forward that through a tunneled connection?
TUI is a simple, universal protocol that does what you need and is natively remote. Whatever I use locally will seamlessly work over an SSH connection.
And it's a big middle finger to the OS vendors who thought locking everyone in by making everything incompatible or ecosystem specific was a winning strategy.
The failure of the modern absurd GUI environment (Windows 11 is a GREAT example) is why I keep coming back to something like a minimalist xfce4 desktop environment. There really isn't a need for all the absurdity.
I've been using openbox for decades now. It doesn't get in the way, and I don't need more.
And TUIs
* Are simple to grasp for uses * Efficient to use (not just resource wise) * Look nice on nice terminals
Notcurses (C++) and Ratatui (Rust) did help ncurses (C) a lot.
I wish TUIs weren't back. I'll take a web interface over a TUI any day. No installing fonts that are too clever, no tweaking my terminal config to get it to display right, no guessing the navigation shortcuts that person thought was best, real text editing with OS standard text navigation, better integration with my password manager, text expander, etc...
I live on the CLI, I have one a hotkey away, but please, technology has advanced significantly since the terminal was the only option, and we have far better options for building UIs now.
Web interfaces aren't any better. They're designed to for aesthetics and not functionality. Not to mention the fact that they all have their own UI idioms that you have to pick up on.
I spent decades using vim and Emacs but having moved to GUIs a few years ago I can't see myself going back.
This whole TUI thing just seems like a fashion trend.
I really don't get terminal UIs that try to rebuild GUI-like functionality. Don't we think that computer interfaces should get better? We're not limited to a grid of characters to pretend to draw lines and shapes with anymore. You can't even display an image in a terminal without a non-standard terminal like Kitty or iTerm.
It's just a shame that we don't have a great cross-platform, streamed, UI system. The web is great in it's own ways, but clearly something could be a lot better for this purpose. Flutter's ok, but not on-demand enough and too married to Dart.
This is because of the failure of the modern GUI environment.
They want a GUI, but, instead, they have to resort to something like this. A GUI in a TUI.
They want something portable. They want something that can run remotely. They want something they can run more safely than having to expose a socket. They don't want to have to bring up an entire desktop.
Rootless windows are effectively dead. That leaves web interfaces (and all of their issues) or doing a TUI, where all you need is an SSH connection that everyone already has.
In the past you could slap something together with Tcl/Tk, and just launch the window over X Windows. That's not so easy today, and no one is running remote X anyway.
The LCD is SSH, and these are the only things that fit.
> That's not so easy today, and no one is running remote X anyway.
I was quite recently, but even then remote X is missing a really big usability piece: keeping a long-running application open on the host and periodically connecting to it from a remote node (concretely: connecting to my server from my laptop). VNC/RDP/etc all do this at the desktop level, but they're pretty mediocre experience-wise.
tmux gives me this for terminal applications without really any compromises. I run tmux for local terminals as well as remote terminals; the hotkeys are all deep muscle memory at this point. It just works.
Agreed. I dread GUI development, hence I never build GUIs. If there were a library for my language of choice that worked multi-platform and used native components then I’d be interested.
> That's not so easy today, and no one is running remote X anyway.
If you:
1. Have a low-latency connection to a decent machine, and 2. Are on a machine that's weak, or isn't yours, or that you don't fully control (e.g. employer forces you to run Windows)
... then you live in remote X apps my friend.
> You can't even display an image in a terminal without a non-standard terminal like Kitty or iTerm.
Sixels are supported by many terminals[0] (several of the terminals mentioned that do not support them are based on GNOME VTE for which support is in the works and, based on the bug tracker comments, it seems to be almost done).
This includes xterm which is probably the most "standard terminal" on X11 you can get.
[0] https://www.arewesixelyet.com/
> really don't get terminal UIs that try to rebuild GUI-like functionality.
Because it's easy to get things done for a TUI, but if I create a proper GUI, my codebase is suddenly more complex. And it's not like there's a solid, reliable GUI toolkit that I can use, they're all riddled with different bugs and caveats.
> Flutter's ok
If you ignore the absolute nightmare that is building applications in Flutter. Even Flutter itself isn't really designed to be compiled by anyone (although, in practice, your distro will shield you from this issue).
> It's just a shame that we don't have a great cross-platform, streamed, UI system.
It's called the web/Jupyter. And no, web-driven UI doesn't have to be heavyweight either, any more than HN is.
It's for speed over SSH text is fast. Graphical redrawing of RDP/VNC/whatever is just slower and tedious in the long run.
i am experimenting with TUI/GUI.
My motivation is avoiding all the piles and piles of extra software dependencies that X and/or Wayland bring in.
In addition (but might only be relevant in my niche platform) is that Wayland is buggy and X is deprecated and unmaintained making making the GUI work there a constant struggle.
Time will tell if it is an improvement
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.
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.
"worst case is trying to develop some small utility like a tool to search in files using regex" - you mean something like: https://wiki.tcl-lang.org/page/ReacTcl+example%3A+Grv ?
This will run on Windows, Linux, MacOS, and Tcl's starkit/starpack system makes it easy to generate a single executable file for each OS that can just be copied over and run without any installation needed.
> There is no guarantee the machine has any version of GTK or Qt installed at all, so to be self-contained
So don't be self-contained. I mean, you depend on an X server or Wayland, right? So why not depend on GTK or Qt being available?
(Of course, it _is_ tricky to be able to depend on any of several versions of these, but still.)
What I mean is that on Windows you can just ship an 100kb .exe and forget about it and it's still going to work 20 years later.
On Linux that doesn't happen. First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed. Second of all, even if you do ship the source code, you're going to be forced to maintain it. If you made an app in GTK 1 (which looks beautiful, by the way, compared to modern GTK), people won't be able to just install it because GTK 1 is so old that it's no longer in the repositories.
An app made in Java 8 runs in the modern VM. An app made for Windows 95 still runs on modern Windows.
It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
I'm not defending this but there was (or has been) enough political motivation and intentionality in GNU/Linux systems to make binary compatibility a hassle. People actually made decisions against backwards compatible APIs, intending to cause issues and forcing open-sourcing.
Binary compatibility means closed source has a chance to grow in an ecosystem. It requires "responsible" developers to put more effort into designing APIs and keeping them alive. It adds complexity that requires a more stable set of long-term developers; in contrast, the constant churn in FOSS requires lower barriers for contributions. With stable APIs/ABIs you have to live with decade-long mistakes. You cannot "just fix it" in a next major bump.
>People actually made decisions against backwards compatible APIs, intending to cause issues and forcing open-sourcing.
You mean openssl? That said, if we can have /dev/tcp, why we can't have /dev/ssl?
> First of all you HAVE to ship the source code if you want it to keep working on every machine because people need to compile it on their machine for it to work, so you're practically forced to open source your desktop app. I know the notion of having a closed source app on Linux sounds weird, but it's more weird that this isn't an option as a side-effect of the how the whole system is designed.
That's so very not true.
Most Linux distros allows for custom repositories. So you can just setup the build infrastructure on your side and then have the users include your repos on their side. No need to open source code and users have painless update notifications.
> It's only on Linux that I feel like the developer is pressured to open source it and make it the user's problem because the system won't provide support.
Lots of users have never seen the source code of their software, they just get the binary package. The pressure you're talking about is imaginary.
This is downright misinformation. There are no 100kb Windows programs that work for 20 years. Every single program on Windows ships half of the system libraries again, just for use by itself. Microsoft couldn't be bothered to version their libc at the beginning ffs.
WINE is often somewhat jokingly called a more stable platform for Windows programs than Windows is but there's truth there.
I have 161kb program from 1992 and it works. I suspect it doesn't use libc. Well, on windows there's nothing useful in libc anyway.
I want to say you could statically link a GUI application, but I'm pretty sure libpthread doesn't cooperate on static linking.
libpthread is fine with static linking. Where you run into issues is libraries like libresolv that use configuration files in a specific path.
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
The article (as I read it) says that Google gave up on the new operating system (where Flutter would have been the default UI toolkit).
I’m not sure if Google actually already gave up on Fuchsia, I’d be surprised if the work actually stopped, but it’s clear now that it will not be a panacea and if it will ever get released and gets some traction, it’s still like a decade away from becoming a major OS.
They laid off most of the people on the Fuchsia team so it isn't getting as much work, but Fuchsia is used on their nest stuff iirc
I don't really want Dart tbh
I dislike Dart, but it does work really well for Flutter. I think if you treat it as a Flutter DSL it's easier to put up with.
One of my former coworkers / dev friend is primarly a Flutter dev, and he's about to give up on it because finding Flutter jobs has become a pain.
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.
Their GUI system (GPUI) is not very mature for use outside of Zed. GPUI is basically a UI framework in the truest sense: a framework for building UI... frameworks/components. It has core functionality for async execution, an ECS for grabbing shared resources, and a div.
It's basically like building a website with div and basic CSS.
gpui-component exists: https://github.com/longbridge/gpui-component
Up until sometime late 2025 GPUI wasn't even on crates.io, and it seems like the GPUI-component ecosystem still promotes using git deps. It was also in "read the code for docs" state for a very long time
It's been a while since I've used it, but there were weird things missing too like the Scollbar was located in Zed's UI component crates instead of core GPUI. Arbitrary text selection also is not possible, which is something I really value about egui.
What I do not like on Zed or electron GUIs is lack of customization. Older IDEs using sdks like Swing, JWT, QT, GTK etc. allowed user to design its user interface using drag and drop. ie compare older IDEs like eclipse or idea and try to create layout which fills screen with information important for you. And then try to do the same with vscode or zed. I like functionality and speed of zed but UI customization is too limited for me. It might be design choice or sdk limit I am not sure.
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.
Are the available FOSS cross-platform frameworks really not that good?
There's at least Qt, GTK, umm, and, I guess Juce and wxWindows, right? Oh, I see there are more:
https://en.wikipedia.org/wiki/List_of_platform-independent_G...
Can you explain what's deficient about the first two I mentioned?
> Qt
Arcane build system. I mean, I guess it technically supports CMake these days, but I have never been able to get anyone else's Qt project to build without much gnashing of teeth.
Emulated native widgets try for pixel-perfect, but tend to feel wrong somehow.
> Gtk
Outside of a Linux/Gtk native environment, Gtk applications are awful. Take GIMP on macOS, for example: it's had window focus issues (export dialog getting lost behind the main application window) literally ever since Gtk on macOS dropped the XQuartz dependence. And that's the flagship application for the toolkit.
CMake support in Qt is perfectly fine nowadays. There are some (optional) custom commands you can use, but generally it's just plain CMake.
So, your critique of Gtk sounds convincing, but about Qt, you seem to be admitting they're offering a less-horrible way to build than how things used to be.
I looked at this: https://doc.qt.io/qt-6/cmake-get-started.html ... and I'll admit they seem to be hiding some nasty stuff under the hood. But it still seems workable. I guess the devil is in the details?
GTK 3 hello world is 150-200mb. They really messed up since GTK 2 was 30mb (like macOS AppKit).
GIMP itself is 62MB on my host, I'm not sure what kind of hello world you're building that's 3x that size.
Dunno, try it yourself. I wrote the hello world with C (12 lines?) and launched it on NixOS in Wayland (sway or niri). Maybe non-Wayland does better?
Granted, not the best measure of memory usage. But the GTK 2 version was 30mb.
Maybe GP means on non-Linux systems? When you have to "vendor" a large number of libraries?
> cross platform
That's one word that should never been used in an design meeting. None of the GUI I've used has managed to do this right. Even Emacs and Firefox. The platform are totally different (and in the case of Linux/Unix, there's a lot of different HIG competing). So trying to be cross platform is a good illustration of the lesson in https://xkcd.com/927/
The best bet should be a core with the domain with a UI shell. And then you swap the shell according to the platform.
I want my applications to look consistent across platforms. Why would I want discord for example to look entirely different between MacOS and Linux? With the current state of things, once I use the app anywhere, I'll know where everything is on any platform.
Take a good look around and check how often people do really change computer platform. And you already have so many things that are different that the "same look" is just an excuse. Gnome, KDE, macOS, Windows does not have the same UX in their file explorer which is a basic utility that everyone has to use. Same with connecting to a WiFi and creating a new user account.
So why would you want Discord to be consistent, when you're mostly using the same desktop (or switch between at most two) for hours.
The thing is when HIG were followed instead of everyone trying to create their "brand", everyone knows where the common actions were. You learned the platform and then can use any app. With the new trend, you would only have one computer, but any new app is a new puzzle to figure out.
I don't really have any issues working out how to use modern electron apps, they all follow very simple UX patterns, I find them much easier to use than the average native wxWidgets/qt app. Simple, consistent UI is less about the color scheme and border radius being consistent and about things being simple and well laid out on a higher level.
Two apps can have different CSS while being easy to understand because the core flows and ideas are the same. While many older native apps feel like junk draw UI with crap thrown everywhere and weird app specific quirks and patterns. Even if it all does use native inputs and windows.
Electron apps use the usual web 2.0 forced keyboard focus antipattern which breaks page up and page down scrolling, so they are difficult to use. Also blurry text rendering.
> The best bet should be a core with the domain with a UI shell. And then you swap the shell according to the platform.
I've rarely seen that turn out very well. Typically it works ok on whatever desktop main developers use, and not so much on the others. That means using multiple frameworks, witht their own idioms and quirks and having to repeat a lot of work. Unless your UI is very simple it is pretty expensive to maintain multiple separate versions of it.
The best way I’ve seen this implemented is having the domain be a library or a protocol/server. For a lot of saas, we already have people writing the mobile versions and the web version..
Yes. It’s more work than dumping Electron on users. Quality often is.
It's not even that cross platform is necessarily bad, it's that we have so many cross platform toolkits and they compete with native ones.
I think we'd all be better off if we just declared qt the standard gui library and rid ourselves of the chaos we find ourselves in
You are not going to believe this... (joking)
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.
A year ago I would have agreed with you, but now anyone can build a perfectly reasonable native app.
What is native on Linux?
What is native on Windows too. These days the term native app is so confused it's hard to come up with a definition that doesn't include electron.
There’s a few options on windows all of which are native. WPF, Winforms and WinUI are all “native”.
> These days the term native app is so confused it's hard to come up with a definition that doesn't include electron.
Electron is _not_ native.
athena[0], take it or leave it
[0]https://en.wikipedia.org/wiki/X_Athena_Widgets
TUIs, apparently. :)
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.
99% of LLM-adjacent software is webslop in a state of perpetually broken churn.
OpenCode for example has not yet figured out "maintain a log of all messages and send that log to the SSE endpoint in the same order to get the next response" and has regular prompt cache misses even with context pruning disabled
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.
Impressively many dependencies? I estimate about 75-125 in the dependency tree, including multiple versions of the same package. Now compare to something written in e.g. C: such a program might have 2 dependencies: libcurl and ncurses.
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.
AI is only good at the work I'm not paid to do
Return to the halcyon security era of curl piped into bash
[flagged]
For the record: I have a terminal open at all times, my life is automated trough Bash scripts and I am a VIM / TMUX user.
With that background, most TUIs are really two steps back compared to a decent GUI. (Wild west navigation/hotekeys, broken copy and paste, lack of integration with the environment, just to name a few.)
The core of the problem is IMHO, that we really lack a decent cross platform GUI platform, which is really integrated into a programming language or part of the standard library.
Outside of Swing (which lacks access to a native browser element), we have Tk (no browser component, no drag'n'drop, at least from Tkinter), wxWidgets (seems that the community is very small and especially its bindings needed to be resurrected at least once), Qt with the ever looming possibility that it will get deshittified to make more money (... and no, KDE is not that important and I doubt the KDE community could take care of a fork long term).
Which leaves us with Electron or the other variants of 'browser component + JavaScript/CSS and callbacks to a local server, which is a really bad programming model (ignoring the memory/runtime overhead for even trivial applications).
The problem is, to build a decent cross platform gui toolkit, one needs a lot of funding and a lot of people (usability, accessibility, design, documentation, testing...). The open source community didn't manage to pull this off (GTK is by now for all practical purposes Linux only) and there is no modern contender for Qt or Swing (with their own problems).
TUIs are no solution to the core problem (and it would be absolutely possible to have a GUI toolkit with a TUI renderer for perhaps 80% of GUI needs), but I understand every developer who chooses TUIs for cross platform UIs given the alternatives.
> which is really integrated into a programming language or part of the standard library.
Not a programming language, but the programming language: C. The toolkit needs to be available as a C API because that lets it a) provide stable API and ABI and b) provide bindings for multiple other languages without having to jump through hoops, especially for other compiled languages (binding Qt to Python might be easy, but bindings to something like, e.g. Free Pascal requires an intermediate C++ library that exposes a C API that itself can be used from Free Pascal - and applications need to distribute it that library too).
Unfortunately the vast majority of GUI toolkits are not writtne in C but in C++ or some other language that makes using them from anything than the developers' favorite language a pain. And really the only mainstream that is written in C is GTK which has a complete disregard for proper backwards compatibility.
(you may think that a library only needs to expose a C API but it can be written in any language, however for something that doesn't have any widespread availability, you may want to link to it statically - however that can be an issue with anything outside C/C++ - as an example i recently tried to make a FLTK backend[0] for Lazarus since FLTK is a C++ library that the devs encourage to link it statically and it would allow creating GUI programs that are self-contained binaries... but statically linking a C++ library -for which i had to first make a C wrapper- in a non-C/C++ turns out to be a PITA under Linux if you are not g++ as that does passes a bunch of magic flags to the linker and impossible under Windows - or at least msys2, so i gave up).
[0] https://i.imgur.com/W6XbLkr.png
Nicely written and I totally agree with you.
I like, that you also added backwards compatibility and ABI stability, two very important and valid points. There is to this day the joke, that the best way to write a binary GUI app for Linux is to target the Win32 API and run it via Wine, if you care for a stable platform. ;-)
I think you are right and completely agree with most of your points.
> wxWidgets (seems that the community is very small and especially its bindings needed to be resurrected at least once)
Which is a damn shame because they are very close to native appearances on both macOS and Windows and are much easier to program than anything Qt. I think it’s the solution I prefer for multi platform GUIs, both as a user and as an occasional programmer.
> Electron or the other variants of 'browser component + JavaScript/CSS and callbacks to a local server
On the other hand, I absolutely hate this as a user. I would lose features and go back to the command line rather than having to deal with this. Everything is wrong in these applications, they don’t support standard keyboard shortcuts, they look weird and out of place and lag where you least expect it.
> TUIs are no solution to the core problem (and it would be absolutely possible to have a GUI toolkit with a TUI renderer for perhaps 80% of GUI needs)
There are a couple of TUI framework that are almost there already. I like the fact that they are useable without fuss over ssh and stuff but I think they are solving the wrong problem. I would rather use something like tmux but that sucks less for the windowing and persistence bits and get more focused and composable CLI. Make a simple REPL with readline so it has a standard and expected behaviour instead of trying to make everything look or behave like an IDE.
OTOH, I really like how this is driving improvement in terminal emulators.
Thank you very much, and I also agree with your points: Electron Apps simply never feel right, even if I work within them all day (VS Code for example).
I also agree, wxWidgets is quite great, although I have to also agree with the comment above, that C++ for a GUI library is just a PITA when used from any other language. AFAIK the consumers from wxWidget (wxPython, wxErlang?, ...) are using a C wrapper around the C++ wrapper to use it.
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
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.
I like TUIs for a lot of reasons, but this one might be the biggest.
> - 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.
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.
It's nuts that software developers are allowed to design user interfaces at all. They're incapable of making a user interface that isn't text. It's like if plumbers designed houses, they'd make all the floors slope downward, because that's the easiest way for pipes to run.
Oh we need multiple windows we can move around/resize? Let's make them text windows. We want people to be able to quickly select options? Yeah make those text boxes. We want to quickly compose documents with some kinda style/formatting? Yeah they'll need to write more text to format it (but let's not make any apps to easily view the text in formatted mode).
Allowed? Many if not most of these open source TUI projects were started by individuals or small teams who wanted to solve a problem for themselves.
It’s allowed. You don’t have to use them.
On the opposite end of the spectrum, you have material and (to some extent) adwaita which look pretty but are absolutely useless for anything more complex than app style development or maybe a file manager
Wtf are you talking about? Give a developer a decent design system, and we are good to go.
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!
Windows has a hot key control for input and display of keyboard shortcuts https://learn.microsoft.com/en-us/windows/win32/controls/hot...
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.
The xfce folks are keeping GTK+ 3.x around, mostly for its advanced theming support. Isn't that quite enough?
I didn't realise. That's good news. Whether it's enough, I don't know the UI space well enough to say.
Qt's license really isn't hard to figure out. If it's free software, you use the free software license. If it's propietary/commercial, you use the propietary license.
You can also use most of the core components (labels, buttons, grid views, image and media players) with LGPL in commercial apps. Only the more complex and more value-adding components like charts are GPL.
I wrote bindings for gtk, it's 16kb of text. I imagine riir of curses will be much more mork.
There is only so much rounding of borders you can do in the terminal! On a 16” MacBook, you can’t have Activity Monitor take up less than about 2/5 of the width of the screen! There is so much padding around every single element.
I don’t need pretty buttons, I need usability and readability. Without having a 50” display!
Somewhere along the way everything got dumbed down and all the info removed. It’s some condescending ‘so dumb ppl can take it in’ marketing bs I hear from time to time. And it sucks! I also doubt it’s true. Fashion be fashion.
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.
This nails it. The fact that the app interface looks exactly the same whether it's running locally or in an SSH session means I don't have to learn it twice. And while some GUI apps (VS Code for example) can be run remotely and still look the same, it takes a certain amount of ceremony to set that up. And worse, that ceremony has to be done for each app and is different for each app.
Running TUI apps over SSH isn't ceremony-less either — you have to set up SSH keys and copy your public key over into the remote end's authorized_keys file — but it's ceremony that you would have already had to do anyway to get access to the remote computer in the first place. And once that ceremony is done, you can now run any TUI (that the remote computer has installed) remotely without any more ceremony.
Power users have always preferred the command-line, since expressing what you want to do as a programming language is of course much more powerful and productive than clicking menus.
To avoid context-switching from the command-line, many essential UIs were made text-only. Another route would have been to integrate the command-line within graphical applications, but few did it -- the main example that comes to mind is Jupyter.
Blender is a 3D modelling program with a scripting language in it (Python). When you open the scripting pane, it's a command line. But it doesn't try to force the whole program to be in the command line, only the part where the command line is actually useful.
TUIs are much closer to GUIs than CLIs. As a CLI enjoyer, I was resigned to the small win that at least many people distinguish TUI and CLI now but then I saw your comment.
There are quite a few GUIs that can be navigated with keyboard, e.g. menu bars can usually be activated with alt or win and single key presses
As I said, the advantage of the TUI is that they avoid context-switching.
Except the part where you switch into the TUI from a normal bash prompt, and your normal bash invocations get eaten by the parser..
Which is essentially exactly the same thing, except your UI is trash relative to a normal GUI
You're not switching, it's all in the same pane, doesn't mess with windowing or focus, your keyboards shortcuts still work etc.
TUIs don't use the command line (ie bash, fish, etc), though. They use ncurses
There are a lot of TUIs in existence worth looking at if one is interested or curious about them [0], [1], [2]
[0] https://github.com/rothgar/awesome-tuis
[1] https://terminaltrove.com/explore/
[2] https://github.com/ibraheemdev/modern-unix
Even before Claude Code, I always see htop as the prime example of a good TUI.
Because we are all working on remote machines these days. Laptops have become thin clients that run fat local electron browsers that connect to the actual computer via http / ssh.
We made our machines 100x faster and instead of running compute locally we just made 100x slower client software.
> 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 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.
The culprit is using web technologies where they don't belong, which Electron is also guilty of. Claude Code is 400k lines of JavaScript for a TUI where a sane implementation in C would be two orders of magnitude less code.
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.
Yup. VSCode is really fast and memory-frugal for an Electron application of that complexity.
Likewise, Gnome has proven that you can write entire UIs in Javascript and have them be quite performant.
Electron (well, Node is a big sub-culprit) and Javascript in general just make it really easy to create a slow, bloated application.
Always has been.
Claude code is react and their desktop app is Electron. But “coding is largely a solved problem”.
> shipping as electron apps that implement a TUI layer as their front-end
A significant number of these apps are nodejs apps so it’s not that much of a leap!
Yeah, I noticed some TUI libraries in npm when I was working on a Typescript project a couple of years back so I'm sure people are doing it.
I really wish that 1Password wasn’t an electron app. Or Spotify. (Maybe I should just use Spotify in the browser).
We need to advocate and evangelize for native apps, like RapidApi on macOS and also Tower.
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.
Except most of the TUIs I’m seeing are god awful with horrible input latency because they’ve reimplemented everything from scratch in python or whatever. Multiple hundreds of ms per keystroke: it sucks.
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.
No, it's just misaligned incentives.
Companies make UI/UX to prioritise first 30 minutes of the experience, to keep user using it long enough that they stick with it. Not the 8h/day work the UI will get when a tool become pillar of your work.
> since ages immortal
since time immemorial?
3rd Sept 1189.
Anything after that is time memorial I guess.
[dead]
FYI this is why I still use Vim sometimes. I am OOM more productive in JetBrains, but sometimes I have to feel like Hiro Protagonist. So, Vim it is.
Sometimes I swear that people are just making up acronyms here to troll people.
I assume you mean "orders of magnitude" and not "out of memory". I have never seen the former used as an acronym before, let alone without some kind of contextual clue. (In typical Baader-Meinhof fashion, I'm sure I'll see it again in the next 24 hours...)
https://news.ycombinator.com/item?id=48001905
Nailed it!
I have just combined those together. I use astronvim as main editor but when I need IDE I switch to Idea. I use ideavim with configuration as close as possible to astronvim. So text editing is the same for me in both programs. Modal editors are still great and they can do a lot of work that looks like magic for AI era trained developers.
Did Hiro even use a keyboard? I remember everything was VR in Snow Crash.
I, of course, pretend I'm Zero Cool.
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.
Window managers are more flexible than multiplexers, but I also think there's a higher floor of effort juggling multiple separate GUI programs than going between tabs and panes in a terminal emulator.
Multi-monitor terminal juggling also probably loses out to GUIs, though for me it's usually IDE or Browser on one and multiplexer on the other. One big zellij session connected to multiple terminal emulators is probably the best way I could think to handle that.
> a higher floor of effort juggling multiple separate GUI programs than going between tabs and panes in a terminal emulator.
Depends very much on your window manager. Tiling window managers such as Hyprland let you open multiple windows and it will automatically arrange them side-by-side. Want one of them to be 60% and the other 40%? No problem, there's a keyboard shortcut (configurable) for that. Have four windows open in a grid arrangement and want to switch between them? Just slide the mouse, no clicking needed so the movement can be as rough and imprecise as you want, OR if you don't want to take your hands off the keyboard then SUPER+arrow keys (also configurable) will move the focus to the next window in that direction. (And if you are in focus-follows-mouse mode then it also moves your mouse cursor to be in the middle of the focused window, so you won't lose window focus by accidentally bumping your mouse and moving it one pixel). Keyboard shortcuts for maximizing and un-maximizing windows, for throwing them onto other workspaces and switching between workspaces...
I throw windows around my screen all the time, and rarely take my hands off the keyboard to do it. It's the fastest, most flow-like window manager experience I've found yet.
This used to not be the case - we've regressed. In the distant past you could just drag a couple of widgets onto a form and update them from a timer.
Not anymore it isn't. "Claude, make this a web app".
Just what I need! A bloated react app to manage my systemd units
Just use something like Tk or wxWidgets.
So just tell it html only if you want.
How does the browser interact with the os? A tui exe has direct access. With “only html” now we need a server of some kind. How is multiple layers and running processes superior to a thin terminal based wrapper around the relevant io?
That said, obviously it depends on the use case. I’m not going to make a tui to interact with locations on a map - a web app makes a lot of sense in that case. But something like lazydocker makes sense more sense as a light terminal based program
A browser is OOM more expensive to run than a terminal app, regardless of what you're running inside said browser
I've literally never met anyone in real life who used a computer that didn't already have a browser running 24/7
Is that because they are much more likely to pay the ultimate price at the hands of the OOM killer?
Can get a GUI with the same prompt if you tell it to use TCL/tk instead of Go + Charm stuff
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.
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.
The low latency and instant startup is by far the primary value add imo. Nothing else comes close.
The inherent lack of UI bloat is an added bonus.
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.
You can make even lighter weight and just as keyboard driven GUIs. The only downside, as you say, is them not integrating with Tmux.
Projects like opencode are making the distinction between GUI and TUI almost meaningless. And that "only" downside is a massive, deal-breaking one. At this point I only have a browser besides the terminal, and I can see that going away soon for the most part thanks to LLMs.
But GUIs are hard to built - mainly because of tech debts around all three major platforms. But nontheless displaying graphics is harder than outputting control chars.
You could whip up decently usable UI in Delphi far quicker than similar one in any TUI framework.
The problem is that world went away from that and into HTML/CSS/JS/DOM mess that makes simple UI things hard and complex UI things slow and/or hard, on top of the bloat.
This is a recent development.
VB6 could have you roll a GUI interface in minutes, so even trivial tasks could have a GUI.
The tools for CDE on Unices were arguably even better but CDE never really got any momentum.
That it’s tough to put together a GUI now is definitely a regression and Microsoft shooting themselves in the feet regularly over the last 25 years is squarely to blame.
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.
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's an aspect I've wondered about, constraints do make you consider what's essential. For example in btop (screenshot in the article) the graphs are rendered with dots at low resolution, if there was another version where those graphs were full resolution is it telling you meaningfully more?
Since the dots in btop's rendering are using the Braille characters, meaning you get six dots in the space that would be taken up by one alphanumeric character, the resolution on those dots is surprisingly high. A maximized terminal on my screen is size 316x86, so that's 316×2 x 86×3 = 632x258 of "Braille dot resolution" (a term I just made up) available for the graphs. Sure, that's lower than the 2560x1600 pixel resolution of my screen, but you're entirely right to ask "Does that really matter?" The graph would be smoother with about 4x more horizontal pixels and 6x more vertical pixels to work with, but I doubt I would glean any more information at first glance.
[dead]
I don’t understand why developers aren’t just learning to use CLIs and be comfortable with terminals even without cute little interfaces.
Are people really that put off by seeing some text on a screen and nothing more? Is tmux that difficult to learn?
I’ve been running Claude with --dangerously-skip-permissions. It’s so nice that I’m not sure I can go back. Pressing continue 15 times is surprisingly heavy, but you don’t notice till you don’t have to do it anymore.
I would try switching to Auto Mode which is their own recommendation as a safer alternative to that but still avoids needing to confirm actions endlessly: https://www.anthropic.com/engineering/claude-code-auto-mode
I’d love to. It’s not available to Claude Pro nor Claude Max subscribers. Eventually I got fed up with waiting and just turned off permissions.
Try an external sandboxing tool. When you need to adjust the sandbox, close the agent, launch it with the new params, and resume the session. It doesn't take long to arrive at a stable configuration; for me it's mostly about rw access to the CWD, read access to other local repos, and access to Nix. Other than that I can just use YOLO modes and not sweat it.
I briefly evaluated a bunch (had an LLM make a list of those that satisfied some basic criteria, then visited READMEs and websites) and chose nono. No regrets: https://nono.sh/
Cool, 1st I've heard of nono.sh. FWIW I've been happy w smolmachines microvms.
Hey, thanks for the tip! I'll also give those a try.
Even if I end up liking virt-free like nono stuff for agents, I am trying to explore and learn about microVM options lately for other development purposes as well. This is a serendipitous recommendation for me. :D
I'm on the $100/m plan and it works.
I associate CLI prompt and typing 100wpm and lots of scrolling logs with l33t, but claude code is more 1992 DOS program vibes.
CLI makes a lot more sense than TUI to me. A TUI program feels like a new thing to learn, a CLI program is just a new tool in my toolbox.
I can see some point to having an auto-updating dashboard or the like, though.
Thank you for this comment. As a principal engineer in FAANG, this the correct answer
I thought that that was the case for me, but then I tried using Claude Code through the desktop app last week and it was so bad. Slow, glitchy... I went back to the TUI in no time.
Can it be much more simple of a reason and that tuis fit into many of our existing tmux based work flows?
Having worked with development since the early 2000s, I think its great that development has become more accessible and I dont particularly like that the old guard tries to gate-keep the idea of "being a developer". Being an engineer I feel requires more credentials, it always has. But if you feel like you're a developer, all the more power to you!
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.
"Claude, write a set of scripts using bash and python that trade this $10,000 on S&P 500 listed stocks until it reaches 5 million, make no mistakes"
lol most depressing comment of the day
When kubernetes got introduced, we didnt want to interact with only webpages/fronts.
So we created tooling we know on the CLI.
Every person here that thinks its AI that caused the resurgence of CLI tools is a vibe coder who just entered the scene this year.
TUIs suck and the only reason they are seeing a re-surgency of relevance is because everything else sucks more along one or more critical metrics. Given the truly incomprehensible amount of CPU and GPU power we have available, this is truly a blight on our industry.
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.
I'm biased towards CLI and reign of LLMs means we're all Unix/text (for) now. So IMO there are many reasons, but chiefly amongst them is UI/HCI design leader Apple throwing out their/industry's interaction design best practices over the last 10+ years.
Embracing constraints and "how it works" used to be at the core of their software ethos.
One thing I like about TUIs is that they can usually be completely operated from the keyboard. Most GUI apps have flows that you need the mouse for, and they’re slow if have to do that often.
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.
> if you make a slightly mistake in coding a full screen app, you get screen corruption.
HOW? The TUI library should handle everything for you. So HOW do... Wait. Did Claude vibe-code up its own set of TUI routines instead of using a library?
The article spends a lot of time talking about how UIs “look” and how they all “look different”. That's not the important aspect to me.
For me what makes a software usable in the long run (after initial learn) is shortcuts and keyboard navigability. Old GUI frameworks had built-in features for this (app-wide shortcuts, underlined letters, etc.). The web has haphazardly copied one of them (“accesskey” attribute), but now this has been completely forgotten. None of the major websites have accesskeys, even for the most frequently used element like the search bar. There are no shortcuts for frequently used functions such as “like”, “reply”, what have you. It's like developers have universally forgotten that the keyboard exists and what it can do.
TUIs don't solve that.
It doesn't really make sense to me. I've been using Emacs and Vim for decades, and have been using Claude Code for months, but I moved to Codex GUI and the VSCode Claude Code plugin eventually. The biggest problem is that monospaced fonts are not really the best for reading, and with coding agents, people should be reading text most of the time.
The current implementation isn't command-line, but a re-implemented GUI in disguise, awkward and even more buggy. Why should I use that over a GUI? I would prefer Electron over those TUI unless I have to SSH.
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.
I'm not surprised at all, if I was to choose from TUI or browser-gui (electron, react, react-native, anything similar) i'd always choose TUI. Good gui design died a long ago. Almost every gui designer needs us to always look at some nonsense animations that serve zero purpose and just make you needlessly wait. There is no such thing as "essential" animation in GUI. And no, plain simple progress bar does not count as animation, but rotating "progress circle" does. GUIs got so unbelievably bloated, it used to be an advantage to have more pixels, as you could pack more information in useful way. Today? Nah. Look at signal (or signal-desktop), it's not even funny anymore. Dolphin used to be good file explorer. Today it's borderline usable, animated so much so that i have to maintain own patched version. One just cannot hide from this, mostly because devs do not understand (or want to acknowledge) need for this stuff to be configurable (instead they more likely focus on stuff no one actually needs. again looking at you, signal.). Or stuff like libadwaita that is likely one of the most arrogant take on gui library ever.
They've been back and we're all taking them further than ever before!
For the past few weeks I've been wrapping up Booba [1], which is developer tooling to combine BubbleTea and Ghostty in WASM deployments (using ghostty-web).
It provides for some interesting deployment patterns both locally, over network, and embedded in a web page. It's intended to be very easy to adopt; at the simplest, one just changes `tea.NewProgram` to `booba.NewProgram`.
I used Booba to make a demo page [2] for our NTCharts TUI library published to GitHub Pages. The repo READMEs have GIFs... this page is all embedded WASM.
There's also new Kitty-Graphics-supported widgets in there (picture, chartpicture); I updated Booba and Ghostty-Web to support it. Still getting the kinks out.
[1] https://github.com/NimbleMarkets/go-booba
[2] https://nimblemarkets.github.io/ntcharts/demos/heatpicture-p...
I do like CLI tools and 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.
Those apps you mentioned are not your typical modern GTK4/libadwaita apps, so naturally you can theme them. It's the GTK4 apps - and ones which use libadwaita specifically - that cause grief.
- Firefox: Uses its own custom rendering engine but interfaces with GTK3. It respects standard GTK3 themes.
- Thunar: Uses GTK3
- GIMP: Since v3.0, they now use GTK3
- LibreOffice: Uses its own visual framework (VCL) but has a GTK3 plugin to draw its window frame and menus, and it also respects the system theme.
None of these use libadwaita, let alone GTK4, so they're not good examples unfortunately.
> so they're not good examples unfortunately
They're some of the most popular GTK apps available. They seems like a good example to me.
The themes I'm using are compatible with GTK4 apps too.
I use niri which suggests installing xdg-desktop-portal-gnome which comes with Nautilus which is a GTK4 app. It's perfectly themed just like the GTK3 apps.
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.
I think well made GUI will always be superior to TUI. And have all the same possibilities and more. But it is also very sad that now decades into this computing thing we do not have any accepted good ways to make GUIs. Or at least widespread enough ways.
Two advantages: - Deliver apps over remote - Superfast keyboard interaction (forced) One big disadvantages: - Limited graphics and advanced UI component support
I would say the optimal UI is a Keyboard driven normal Desktop app. An app that can take full advantage of graphics elements of a desktop app but is lightning fast to interact with thanks to that it's keyboard driven. Very few people build apps like that though. Sure there are keyboard hints in many apps but they are usually not 100% guaranteed to cover all cases and are sometimes an afterthought.
Am I missing something: "[TUIs are] easy to automate". What am I not seeing or know about? I had to go crazy mad routes of automating TUIs with `tmux` just to get to some repeatable process.
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.
I kind of wish we had HTML but for GUI. Imagine if you had a "gui" flag in terminfo and you could send an escape sequence on stdout after which you could send out screen updates as a stripped down form of HTML on stdout and receive events on stdin. I mean something that can describe the simplest bog standard Windows 95 application with a menu bar, side bar, dialogs, buttons, and proportional text. Otherwise we could offer a GUI for applications over SSH by having the terminal open a local TCP socket connected to stdin/out and launch the user's browser, implementing the most barebones CGI.
HTML does describe GUIs though. Browsers are engines that turn a text description of a GUI into a rendered GUI.
I get your point, it does feel like there's something different, but I'd suggest that there is no black and white line, instead there's a spectrum, with fully native local UI at one end and fully declarative remote GUI at the other end. HTML and the web exist somewhere towards the latter.
There have been many attempts at points all the way along that line though, and every point comes with trade-offs. Performance degrades, OS-native components are eschewed, programming gets higher level, etc.
We need lightweight HTML/JavaScript applications that aren't an entire web browser. You already have a web browser installed, you shouldn't need yet another copy of Chromium to run some HTML/JS files. Because browser makers cripple HTML files run from your own computer (can't fetch any files, even from the same directory), you are forced to start a web server just to run HTML and JS files from your own hard drive.
If you have python installed, you can start a web server with a couple lines of shell script. Is there any really good truly lightweight webserver? (Something under 256KB)
No we don't. Browsers are wrong abstraction for GUIs
Take a look at Wails, Neutrino, etc.
I worked in a lot of places where mainframe applications survived along with their more moder replacement for years, because experienced users were orders of magnitude more efficient using old mainframe TUIs than the clunky and slow web interfaces that replaced them.
Even in the PC world, the move from DOS based TUI programs to windows GUI in applications like POS was not without some user trauma and insatisfaction.
I think Midnight Commander is still the most advanced TUI there is. It has so many hidden capabilities that you may not even know about. You can be connected over ssh to another computer, while browsing the inside of a compressed zip file and previewing the content of the file inside of it . If you enable lynx motion and case insensitive - you are navigating across folders so much faster than just trying to "cd" and "ls"... It's impressive that this category of file managers has worked the same way for more than 40 years - the same shortcuts, etc.
I totally agree with the author that Windows GUIs and MacOS GUIs are getting worse with every iteration. For my own side project I used ImGUI and it's working great for my purpose.
It's by far not as beautiful rendered as the native OS layers, but easy to navigate and a good foundation for cross platform GUI development. And I got it even approved for the MacOS app store. Here's my write up: https://marchildmann.com/blog/imgui-mac-app-store/
I'm pretty sure dismissing flutter is ignoring reality. It, and more so dart, are not popular on HN, but it definitely is a popular and still in development truly cross platform framework.
Where would one go to familiarize one's self with Flutter and with dart?
https://flutter.dev/
https://dart.dev/
https://dartpad.dev/
I saw that - and it doesn't seem to fit the bill. First, Dart is a language, not a GUI toolkit; and Flutter seems to be focused on Dart. It also seems to be opinionated in other ways in the introduction, rather than exemplifying its flexibility and adaptability to _your_ platform, programming language etc. Most importantly, it seems it will get you to produce apps whose UI fits a mobile phone rather than a desktop. I also get the sense that Google has strong control over this project.
Maybe I'm mis-perceiving - but that's the impression the flutter.dev site gives people.
Dart is the language flutter (the gui toolkit) is written in.
I've no idea what you mean regarding: "rather than exemplifying its flexibility and adaptability to _your_ platform, programming language etc".
It can produced mobile, web, or desktop apps from the same codebase... Dart and flutter are open source projects supported by Google, like android and go lang.
Seems like you're looking for excuses not to use dart/flutter. That's fine but you could just say you don't want to use them.
> Dart is the language flutter (the gui toolkit) is written in.
Well, that's already a strong barrier to its use. When creating a GUI for an app, the toolkit must offer bindings for the language you're using, it's not you that needs to learn a bespoke language just to use the toolkit.
> It can produced mobile, web, or desktop apps from the same codebase...
That's the thing - not really. It seems it can produce a web or a mobile app while will _run_ on the desktop. But mobile and web apps do _not_ work as desktop apps, nor the other way around; the whole UI/UX language is different... even if some companies try to foist mobile apps onto desktop users.
Obviously if you are unwilling to learn a new language then yes flutter is not going to do it for you. Flutter is Dart's gui framework and it's excellent. Dart however is itself a lovely language and extremely easy to pick up if you have any knowledge in programming. Much easier than learning the flutter framework to be honest.
> That's the thing - not really.
If you were to spend some time learning dart and flutter you'd know this to be false. But I'm not here to change you mind as you've already made it.
If you've done some SwiftUI or Flex or WPF or similar, Flutter is pretty easy to pick up.
Dart is really easy to pick up, it's a beautiful language imho.
What popular desktop application is written in flutter?
Asking honestly, because none of the ones I use is.
A ton of industry applications are written in flutter. Point of sale systems, automotive interfaces, bespoke industry applications within offices, etc.
The install base would be huge, and it's a solid cross-platform option.
localsend
I love TUIs because so much of my dev career was ssh/mosh/tmux to remote servers and working where the fast network bandwidth and computational crunch lived.
I was vibe coding a layer on top of textual last week that allows me to plug in both interactive and information display Python functions into a TUI grid. Really simple stuff, with textual doing the heavy lifting.
One of my first jobs was working on Telephony User Interfaces (TUIs). Everytime I see the term TUI I can't help but think of that.
For people who don't know this version of TUI, it's the ole, "Press 1 for X, Press 2 for Y" kind of interfaces that you use over a phone. Think voicemail text-to-speech and automated speech recognition.
I think there’s also perhaps an organizational explanation.
A reasonable TUI can be built without any design or frontend people even looped in.
Collaboration and coordination tend to slow down processes and flatten outputs.
> I do not necessarily argue for cross-platform support, but having one such solution would help reduce the electron and TUI dependency.
I think this is the primary reason. I feel like whether or not there are good native libraries things were bound to converge into cross-platform preferencing since it's cheaper to produce and maintain.
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 only reason CLIs and TUIs "came back" is because we're still in the early stages of this paradigm, things are moving fast and building a strong GUI UX takes just as much time as building out the backend functionality. So CLI and TUIs are used because they save time, skips the need for building a time consuming GUI. Also building UI is hard.
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."
TUIs are back because the web got too bloated.
And desktop app are tuning into bloated website
I make some things GUIs and some things TUIs. The TUIs are easier to work with Claude Code and Codex. We can co-work on many things together because the LLM harness reads TUIs very fast. You can do it with GUIs but that's much slower, and maintaining two separate interfaces into these things isn't worth the trouble.
I spend all day in a terminal multiplexer (zellij) with neovim and other splits. Using things like k9s / btop / lazygit / lazydocker helm / stern / whatever that systemd TUI I saw in here and started and will check out later just keeps me focused in one window, and that’s pretty cool
Also I can use the same tools on macOS and Linux machines over SSH. And I can use these tools on headless machines.
A GUI is a huge regression here.
I think most people are missing the forest for the trees.
TUIs are popular because once you use a piece of software that doesn't have a poorly-written GUI library full of animations bogging it down, you don't want to go back.
It's hard to make a TUI that isn't snappy, no matter how much useless eye-candy it has.
I have a theory that we’re moving back to TUIs because they’re responsive and will be compatible with wearables. It’s easy to overlay just text using TUI’s onto a visual portal.
> Reviewing code is important, but it's only 50% of the learning process, at best
I don't know about everyone else, but the code I reviewed as a Junior was high quality code I was expected to learn from. That's entirely different from doing code review on whatever CC outputs.
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.
I think TUIs have started to become popular again a few years ago, before Claude Code was released?
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 popular not because they're TUIs, but because they're simple. We didn't need the bloat in the first place.
Cuz they're cheap and people don't care. Same reason by electron interfaces are so common
The bottom of the post contains an interesting suggestion, for us software developers to read one of three 'basics' books on UI: "Nielsen, Norman or Johnson".
Can someone who is more knowledgeable about these help compare and contrast these three texts a bit?
A React app that renders to text running inside a terminal implemented using electron.
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"?
Shoutout to k9s. Fantastic tool.
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.
It's based on trends, momentum and social signaling more than anything, like most things in technology and society. Humans are herd animals.
I am affected by it also and have always been fond of TUIs in a nostalgic way.
They are back because modern languages (Rust, Go) have made it pretty straight forward to build them. Ratatui and such allow you to write a TUI really quickly without needing to deal with VT100 arcana.
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.
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.
It was always there. k9s for instance, it started getting noticed recently. With coding agents, it is even easier to build.
Terminals are great but they seem to be turning into literal browsers and it's starting to worry me.
Just wait. Soon the terminal will be electron based. Showing electron running inside it somehow...
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.
Somewhat ironic is that people are using them to create generic web apps like they are going out of fashion.
They were never really gone, just maybe introduced to a new audience a little more lately which is great.
Some of us never switched to gui. Who wants to stop working to move a mouse around?
TUIs are extremely more portable, and offer a more uniform UX across platforms.
They are so portable that Windows needs a separate terminal emulator to be able to run *nix tooling properly.
In any course, if the UI does not make any sense, the project should be failed.
Failing projects over bad UI teaches fear, not design. Good interfaces come from iteration and feedback - which is exactly what user-centered design is about
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.
CLI
Dumb question and slightly off topic, but is there a reason why so many AI tools are CLIs … as opposed to just an API or another interface?
I feel like I’m missing the obvious in why there feels like an explosion of CLI tools lately, related to AI.
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.
It's well known how it works. If web browser is efficient, it just invites webdevs to spend all the extra resources until it's slow again. Wait for AI assisted mouse cursor.
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.
And for those of us devs, they never really went anywhere. vim was the most popular editor on HN 15, 10 years ago, still very popular 5 years ago, still popular today.. and that's just an editor, all the other tools like top and its descendents never went away.. I'll believe "TUIs are back" or in some kind of uprise when I notice my non-developer friends and family using them for anything. The most dominant UI today is the mobile app, that's not changing. Limited to professional use (i.e. doing work for someone) and not all use, TUIs aren't touching either web apps or native GUIs either.
Many "non-technical" folks who have interacted with virtual 3270 terminals for all sorts of mission critical tasks would disagree sharply with that assessment. And those are essentially TUIs.
Do they use it for generic computing stuff, like, reading and replying to emails, or specific tasks?
Yup.
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.
if ai makes native rewrites cheap, "write once run anywhere" matters a lot less. tuis stick around for dev workflows, not for shipping to users.
I do get that, but developers like native UI too. You can tell by how much we gripe about Electron!
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.
I agree, the LLM porting things is a game changer.
Does it also follow that we can have pretty much any shape for valuable apps? API, CLI, TUI, Web, SwiftUI, WinUI...
Yes. Developers are conditioned to expect the only convenient answer is a TUI (actually, a CLI; TUIs are show-off projects most of the time) and, if you really want to go all out, Electron. That's not the case anymore.
I'm with you here.
In the "before times" an API and web UI that double times as native via Electron was the biggest bang for your buck.
CLI would be a hacker's side project, TUI would be them showing off more. Native would require hiring a team of specialists which is a total non-starter.
In the "after times" API and CLI are getting more love rebranded as MCP and tools.
To the parent topic, I suspect "build a TUI around my CLI" is a slam dunk for an LLM text in / text out machine which is why there is a resurgence of these too.
Hopefully that is the gateway drug to "build a SwiftUI around this", and an antidote to doing everything in Electron.
[flagged]
The guidelines are pretty clear that basically all of this comment is not ok, and that this kind of comment is net negative for the quality of the site.
> Be kind. Don't be snarky.
> Edit out swipes.
> When disagreeing, please reply to the argument instead of calling names.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
It seems pretty clear that saying most TUI projects are show-off projects does not mean all TUI projects are show-off projects.
> It seems pretty clear that saying most TUI projects are show-off projects does not mean all TUI projects are show-off projects.
Which ones are show off projects? Examples?
Be objective.
https://hn.algolia.com/?dateRange=pastWeek&page=0&prefix=fal...
That's a good start.
Let's check the first one:
Systemd-manager-TUI: A TUI application for managing systemd services
Somebody said that they use this, so it is not a 'show off' project.
You realise you made a silly sweeping generalisation right? People actually use them.
I don't know why you're so aggressively attacking the idea of people making projects to show off.
The claim isn't that zero people use them, or that all TUI projects are made to show off. But most of the TUIs you see land on HN are things somebody made to play around with a technology / scratch a momentary itch.
No shade on those people; making a project that brings the author joy is an awesome reason to make something, and sharing it with folks here is one of the better things about this site. But the TUIs you see here are, by and large, not aiming for (and not going to get) broad adoption.
> But most of the TUIs you see land on HN...
This is the main problem.
If you're using HN as a benchmark that most TUIs are show off projects, I don't know what to tell you other than you're in a bubble.
Every time I read a comment like this, I flash to the episode of the Office where Michael steals one of Dwight's clients while Dwight is on the phone with him in the car. He pitches the client, and Dwight screams into his phone "ARE YOU SAYING YOU INVENTED PAPER?!"
No, friend-o, I'm not saying htop and emacs are show-off projects --- though everyone I know who uses Emacs (myself included) uses graphical emacs.
My point is that most developer tooling is CLI, not TUI; most developer tools are shop jigs, not packaged tools. Though most of the packaged tools: also CLIs!
All of them can very quickly be made into native UIs, though.
You'll get further on HN not calling people "very dishonest".
> I'm not saying htop and emacs are show-off projects...
> TUIs are show-off projects most of the time.
Your statement and anecdotes means nothing and are meaningless since you provided 0 examples of the preported "show off" TUI projects.
Maybe you should re-read what you said again before backpedalling after I gave solid counter examples and you provided none.
The screenshot in the post demonstrates show-off TUIs.
That git TUI doesn't offer anything over `git` CLI.
The network / battery / performance TUI is redundant with the tools in the window menu bar.
I love the aesthetic of TUIs but their actual day-to-day install base and usage must pale in comparison to CLIs and GUIs.
The whole point of a TUI is that it is faster than typing hundreds of commands and options you're likely to forget and made a mistake on.
That is not 'showing off'.
And you providing anecdotes based on a single blog post doesn't change that.
TUIs are not for everyone sure, but they also save developers a lot of time typing and using a mouse.
I don't even like TUIs and this is obvious.
LLM reimplementations for parallel versions are going to be fun to maintain, eepecially when AI market maturity ends the era of AI firms subsidizing coding tools as part of their marketshare competition efforts.
If you think it’s all a house of cards, obviously none of my arguments hold. I’m not going to hedge that every time I write anything that intersects with AI though.
> If you think it’s all a house of cards, obviously none of my arguments hold.
I don't think its all a house of cards; LLMs are real technology with real utility, in coding and lots of other domains.
They are also massively and unsustainably subsidized for certain uses (and the increasing crackdowns on repurposing the subsidized services for other uses should make it clear to anyone that the subsidies are unsustainable, and that there is a very clear focus on owning certain markets before when the music stops motivating them.)
Sure, for small projects. Otherwise, you'd better have a solid plan in place for keeping your business logic in a common core, otherwise you'll just be writing N separate implementations where N = number of target platforms.
Even in a world of agents, less code = better code.
Sure, I hear this (with current models). But consider the UX complexity of a typical TUI. Even with a TUI framework, you end up with serious coding lifts just to get things that the all the current native UI frameworks give you for free.
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.
- You don't have to ship Wine with it, you can just make it a runtime/package dependency. Most distros have Wine in their repos anyways, so there's no need to bundle it. I don't see this conceptually being any different than shipping a Python app for instance.
- You can make Wine apps inherit the system theme, well, at least the colors. Although it will still look out of place, but it's not much different to the issues with running a Qt app in GNOME, or a GTK app in KDE. Wine in this case can be considered as just another UI toolkit that has the same problem that all UI toolkits have in Linux.
- Finally, the resource overhead of Wine is far, far lesser compared to Electron, which is a basically packing in a full-fledged browser.
how's that any different than electron, it's also sticking out with all of its widgets being different than native
Materially, it's not. Which is what I'm arguing.
CLI. Wtf is a TUI? LLMs say it has some to do with interactivity in a menu or something, but believe me, we had this all in the 80’s. Nothing new here, but the truth is the CLI is better faster and cheaper. Pick all three.
CLI is "run a command, get output, drop you back at your shell prompt". TUI is a full-screen interface inside the terminal which you stay inside of, no longer interacting with your shell.
I think that’s what we used to call a program. Things like vi and wordstar seem like they’d qualify.
Yes I agree, something like vi or GNU nano is a great example of a TUI. The meaning is drifting a bit but I think the distinction is useful: a CLI program is one that you can invoke from a Makefile.
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.
My terminal has not been ensh*ttified. I used the Internet for work, for knowledge, more than I use it for entertainment. One of the reasons I like TUIs.
I’d love it for my Mac if my wall paper can be a TUI app of my choice.
Interact as needed, matrix screen saver when idle to prevent burn in.
I don’t see terminal apps as heavy at all…
How to make them a wallpaper thats interactive I wonder…?
Funny if I just search it… PlashApp by Sinde, Set to Termix docker and BOOM :)
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.
Luke Smith was too early on this.
There's something disgusting about the use of characters for graphs/charts on a bitmapped monitor. Trust nerds to find a way to make stuff ugly!
Were they gone?
VB6 was the peak of desktop GUI app development change my mind
Delphi.
Why am I back on the terminal and 40k lines deep in my own ai-workflow tui? Two reasons: 1) AI writes my dotfiles. It fucking rules. 2) charm bracelet tui ecosystem in go is ace and ai writes it well.
Because now we have a young generation nostalgic of their parents experience in the 1980-90's, and that includes the TUI experiences we were stuck with back in the day.
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.
GUIs are being developed for first 30 minutes of use.
It seems that barely anyone thinks about what GUI should like for app you use hours at a time for days at end.
About only software that's half decent for it are IDEs (and probably some industry-specific niche software I'm ignorant of)
> 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.
Claude Code is 600 Kloc... insanity. It's definitely possible to write crap TUIs.
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.
Hate to be this guy but it’s Xerox PARC, not Park.
That and "loosing", but I gotta admit, I suddenly love typos and mistakes like this letting me quickly know the post wasn't fed through an LLM.
Fixed both issues. Thanks!
ahh the classic - see one anecdote - then create a narrative that the world is changing.
if TUIs were truly back - as DHH would like you to believe - his money maker - Basecamp - would be available as a TUI, Salesforce, Workday, Bloomberg etc would be available as TUIs. Though Bloomberg is the closest to a TUI.
but let's continue to delude ourselves.
Yeah. I expected article to give much more thorough analysis and set of observations and trends. As far as the actual observation of popularity of TUI, the only relevant part is claude and codex. The rest is about his personal opinion of TUI (vs other UIs)
Nobody here (especially top comments) seems to mention this.
Very low on the actual information side.
> TUIs are Back
Citation needed?
[dead]
[dead]
[dead]
[flagged]
Developers often say that TUIs are better. But this is largely a matter of taste. To be honest, outside the programmer class, how many groups of users actually like TUIs? Very few. Linux is lighter, and these days even gaming through tools like Wine/Proton has improved a lot. So why do Windows and GUI-based systems still sell more and get used more widely? Because most people prefer wrapped UIs. They prefer interfaces that visually package the system for them. Electron has real problems: memory usage, deployment bloat, and ecosystem fragmentation. But if you move too far toward TUI-first tools, your market target becomes much smaller. So the real question is: why are TUIs coming back in the AI ecosystem? My answer is: AI FOMO. Seriously, why are AI-integrated IDEs like Cursor and Antigravity becoming popular? Even when AI chat is built into the IDE, the IDE often freezes or slows down. If you just open a terminal, it is much faster. So yes, TUIs are attractive in AI workflows because they are fast, direct, remote-friendly, and easy to automate. But explaining their return only as a failure of GUI is too technical a view. There is also a social and market reason: people want access to AI workflows as quickly as possible, even if the interface is not what ordinary users would normally prefer.