Ask HN: What is your opinion on TUI applications
14 comments
I tend to run all my terminals in Emacs, which TUIs tend to interfere with (e.g. providing their own keybindings which clash with those of Emacs; providing their own panes/scrollbars/etc. which don't have any of the functionality that Emacs provides; etc.).
I'd much rather have application functionality provided by a CLI, over stdin and stdout; and have Emacs provide its TUI-like layer on top.
I don't mind short-lived TUIs, like config wizards; but would still prefer a CLI that prints a few lines to stdout and reads text from stdin; rather than curses-like things that attempt to print whole "screens" at a time, and are driven by a mess of control characters and internal state.
The worst ones are those that (a) want to live for a long time, and (b) hammer the terminal with updates despite no user interaction taking place. These AI agent TUIs tend to be the most obnoxious; e.g. having a bunch of "spinners", which would traditionally be placed at the end and updated using backspace, but for some reason these AI companies have implemented by redrawing the entire screen, based on some HTML/DOM/React layout algorithm; with the result being a whole bunch of CPU & RAM spent, and a headache from staring at the flickering mess it draws.
I'd much rather have application functionality provided by a CLI, over stdin and stdout; and have Emacs provide its TUI-like layer on top.
I don't mind short-lived TUIs, like config wizards; but would still prefer a CLI that prints a few lines to stdout and reads text from stdin; rather than curses-like things that attempt to print whole "screens" at a time, and are driven by a mess of control characters and internal state.
The worst ones are those that (a) want to live for a long time, and (b) hammer the terminal with updates despite no user interaction taking place. These AI agent TUIs tend to be the most obnoxious; e.g. having a bunch of "spinners", which would traditionally be placed at the end and updated using backspace, but for some reason these AI companies have implemented by redrawing the entire screen, based on some HTML/DOM/React layout algorithm; with the result being a whole bunch of CPU & RAM spent, and a headache from staring at the flickering mess it draws.
Love TUI apps, hate that there isn't a clean way to control native scrollback. It leaves you stuck between manually managing it via awkward hacks on the current visible screen, or not using it at all. I've been working on an LLM harness TUI for a little while, and this specific part has been the most frustrating (in conjunction with tmux).
TUI applications are necessary when most of your workflow takes place in the terminal, and their functions are embedded almost like a pipe into that flow. Unlike graphical desktop applications, where you find multiple ways to interact with data, TUI applications tend to be more rigid in how things are done. When it comes to covering a minimum number of user stories, and that user already works in the terminal and will continue in the terminal after finishing with my application, I opt for a TUI.
Sometime back I have played with Textual TUI framework very neat and good. I also feel implementing a good ui rich feature in TUI is very challenging and not great. Having said that,
I personally started liking command line tools Claude Code cli, codex. I feel they keep me focused, than the editors ai copilot window, like in visual studio code or cursor. I also see opencode UI is neat, but not really felt comfortable using it, may be I have to spend time and get used to it.
They rock. I've made a couple which act as proxies for previously web-only activities. e.g. a Github Issue manager app which generates a little kanban board for me locally. The barrier for entry feels much lower and doesn't have the same "spinning up a new next.js app" fatigue. And I echo your thoughts with design consistency, having it just inherit your terminal theme makes for a nice visual experience. My favourite in this new wave of tui apps is micasa.dev
uh, micasa.dev has a nice concept, I should investigate that. Thanks!
No problemo! I built almost the same app just with a web interface because I couldn't sell my tech illiterate fiancé on a TUI app. I'd have used micasa if I was rolling solo
I'm surprised that Vim is not on the first place here. Great TUI application. However, the about the TUI applications which I use is extensibility. For example, FZF is just a picker, but it has a ton of extensions. Another TUI I like is the interactive mode of Khal (calendar). However, apart from TUI it allows to be used through CLI which allows you to make your scripts on top of it.
I was a fan, until I found in developing them, the same friction of a frontend developer.
All of a sudden, I realized that the command line is already the TUI I want.
Commands can be piped, while graphic interaction cannot.
Now I rely on standard input and standard output, and `fzf` for all the rest.
I agree. That's why I don't use `mc` I find `cp *.pdf ~/Documents` much more egonomic
I think people have started to liek TUI applications since Harnesses have started working through the terminal
i love k9s, it iss the best tui I've seen before the AI era(there are too many TUIs in the AI era, I can't keep up with them)
Design-wise I personally prefer the color, font and sizing consistency. I love the fact that keyboard is first class citizen and would prefer to use TUI to gtk/electron/windows-ui wherever possible.