RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
68% Positive
Analyzed from 8201 words in the discussion.
Trending Topics
#tuis#tui#more#gui#don#terminal#claude#code#text#apps

Discussion (225 Comments)Read Original on HackerNews
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.
Claude code is almost there
https://levelup.gitconnected.com/theres-a-react-app-running-...
We need to advocate and evangelize for native apps, like RapidApi on macOS and also Tower.
A significant number of these apps are nodejs apps so it’s not that much of a leap!
Jokes aside, I don't understand how devs can bring themselves to ship such inefficient apps.
since time immemorial?
Anything after that is time memorial I guess.
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, of course, pretend I'm Zero Cool.
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 :)
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.
The inherent lack of UI bloat is an added bonus.
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.
Are people really that put off by seeing some text on a screen and nothing more? Is tmux that difficult to learn?
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.
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.
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.
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.
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.
Also ctrl + [ is standard terminal/ascii for esc so that might be a bit more ergonomic than reaching for esc
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 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!
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.
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)
Also just to be pedantic: https://stackoverflow.com/a/5036294/10469162
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.
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.
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?
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
It's called the web/Jupyter. And no, web-driven UI doesn't have to be heavyweight either, any more than HN is.
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
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
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).
It’s allowed. You don’t have to use them.
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.
- No distractions from visual content
- Extreme efficiency with keyboard
- 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.
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.
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
[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.
I don’t know if TUIs will be the answer, but it’s an interesting development!
A GUI is a huge regression here.
TUI are snappy, accessible over ssh, small screen friendly, easily embeddable in zellij or other multiplexers, easy to copy paste from... Amazing.
Lucky you. I avoid electron apps because I'm limping along with 16gb.
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.
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/
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.
Asking honestly, because none of the ones I use is.
https://dart.dev/
https://dartpad.dev/
I am affected by it also and have always been fond of TUIs in a nostalgic way.
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.
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'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.
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.
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.
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.
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.
I am, in a proverbial sense, buying puts on Electron.
Does it also follow that we can have pretty much any shape for valuable apps? API, CLI, TUI, Web, SwiftUI, WinUI...
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.
Can someone who is more knowledgeable about these help compare and contrast these three texts a bit?
Don’t fall for this.
Are you saying GUI "the real deal"?
Seems like it could have gone differently. Feels like the time could be ripe for something like a "declarative gui spec."
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.
JS literally destroyed the software landscape. All the bad practices advertised as best.
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.
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.
Nobody here (especially top comments) seems to mention this.
Very low on the actual information side.
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.
Citation needed?
Bad UX has been normalised so far that people write whole articles set in this anti-world, “why TUIs are back”..
The whole situation is like if we invented flying cars, but to get to the parking, we must ride horses because regular cars are not good enough now that we have flying ones, and horses are cheaper and you can ride them without a licence.
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.