Get the top HN stories in your inbox every day.
qudat
_jackdk_
I don't think that's true, because it appears to me that the upswing in new TUI programs predates Claude Code's takeoff.
saidnooneever
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.
heavyset_go
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.
lucumo
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.)
criley2
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.
rahen
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.
_jackdk_
What a fascinating modern age we live in.
undefined
agumonkey
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.
orbital-decay
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.
paradox460
>try making a DAW in it
The very early DAWs kind of had TUIs, to be fair. Things like the Fairlight CMI
agumonkey
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.
carlos_rpn
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).
cmacleod4
"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.
rahen
> try making a DAW in it...
It would in fact work pretty well for a tracker.
MisterTea
> 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.
horsawlarway
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.
MisterTea
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?
TremendousJudge
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
antiframe
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.
ctippett
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.
copperx
> 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?
bostik
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.
allknowingfrog
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.
insane_dreamer
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.)
undefined
cassepipe
> 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.
mr_mitm
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.
lucasoshiro
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...)
kombine
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.
cassepipe
and if you really need the SCREAMING, vim got you covered. Just type your word normally , select it in visual mode and type gU
IBCNU
fellow Caps Lock to Ctrl remapper (and neovim) here...
keithnz
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.
TranquilMarmot
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.
bonsai_spool
Ctrl-[ is accepted across Vim installs
olorion
When using Ctrl where caps lock ususally is, this can be a very comfortable "pinkies out" manuver.
cassepipe
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.
canthonytucci
If you’re on windows, powertoys is a set of first party customization utilities, one of which is a pretty nice keyboard remapper.
pilgrim0
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.
MarsIronPI
> 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.
wpm
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.
saratogacx
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)
tommy_axle
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
cassepipe
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
tern
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.
mghackerlady
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
undefined
tuvix
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!
cassepipe
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.
jeremyjh
It works in bash and zsh at least.
zmmmmm
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.
ho_schi
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.
walrus01
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.
papyrus9244
I've been using openbox for decades now. It doesn't get in the way, and I don't need more.
danpalmer
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.
stdatomic
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.
__alexs
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.
giancarlostoro
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.
bbkane
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
serial_dev
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.
mghackerlady
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
giancarlostoro
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.
airstrike
I don't really want Dart tbh
danpalmer
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.
undefined
AlienRobot
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.
cmacleod4
"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.
einpoklum
> 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.)
AlienRobot
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.
thayne
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.
victorio
You are not going to believe this... (joking)
einpoklum
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?
MrDOS
> 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.
hombre_fatal
GTK 3 hello world is 150-200mb. They really messed up since GTK 2 was 30mb (like macOS AppKit).
skydhash
> 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.
mghackerlady
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
Gigachad
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.
thayne
> 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.
tootie
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.
landr0id
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.
jbvlkt
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.
gray_-_wolf
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.
spankalee
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.
whartung
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.
tonyarkles
> 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.
cedws
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.
einpoklum
> 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.
badsectoracula
> 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.
WhyNotHugo
> 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).
zozbot234
> 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.
sys_64738
It's for speed over SSH text is fast. Graphical redrawing of RDP/VNC/whatever is just slower and tedious in the long run.
worik
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
CopyOnWrite
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.
badsectoracula
> 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).
CopyOnWrite
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. ;-)
kergonath
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.
CopyOnWrite
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.
ohnei
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.
wren6991
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
allthetime
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
MarsIronPI
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.
polski-g
Check out the Crush agent harness. It's very impressive.
llbbdd
Return to the halcyon security era of curl piped into bash
nothinkjustai
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.
llbbdd
AI is only good at the work I'm not paid to do
azuanrb
[flagged]
0xbadcafebee
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).
ninth_ant
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.
mghackerlady
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
robinhood
Wtf are you talking about? Give a developer a decent design system, and we are good to go.
abhinavsharma
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
nrmitchi
> - 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.
mbreese
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.
estimator7292
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.
itsboring
I like TUIs for a lot of reasons, but this one might be the biggest.
JamesStuff
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!
maxrev17
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.
whatever1
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.
Get the top HN stories in your inbox every day.
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.