It’s not easy to build a good tui though. Like fe compare Claude code and opencode. Opencode is an atrocious approximation of a window system as a tui.
Building a TUI is easy now
171–180 of 262 posts
Re: Building a TUI is easy now
#172Earlier quoted context omitted.
Here's why I use them: many modern graphical applications are extremely wasteful. TUIs are typically small, low footprint applications that don't come bundled with a browser or webview. I don't need yet another electron app for every little thing.
I’m definitely not advocating more little electron apps, and I’m totally with you on TUI’s benefits. I’m bemoaning the lack of imagination that has ended us up here and not in a situation where we can have, say, a small, low-footprint application that can deliver a more structured UI with minimal dependencies. It’s not an impossibility, it’s not even that difficult to imagine, we just don’t have the exact technology.
I think for the time being, there's no way to get around writing native UIs to get a native experience. Any sufficiently high level APIs will have to give up something. TUIs for me fill that niche because across any POSIX-compatible interface they will generally work the same, and modern high level languages make cross-compiling to terminals a breeze. Now to write a native UI across Windows, MacOS, Wayland and X11, that's a different story.
Re: Building a TUI is easy now
#173I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s…
What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore.
I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.
Re: Building a TUI is easy now
#174I genuinely don't understand the TUI obsession for LLM applications. Go watch copilot drive VS2026 if you've never seen it in action. There is no way you are going to be able to communicate this same amount of information via plain text in the same amount of time. I can catch a lot of bad stuff mid-flight because I can actually multitask my UI and click into diffs as files are edited in real time.
It's LARPing.
Everyone knows all the best programmers are using the command line firing off one line Awk scripts that look like runic incantations occasionally opening vim to do stuff at blazing warp speed.
So the AI tools people build want to take on those trappings to convince people they are serious tools for grown ups.
Ignore that they are basically a full web stack React/CSS conglomeration - feel the L33t hackerness of 'using the command line'. No IDE like a scrub developer you are using a text console, you are a real programmer now.
Re: Building a TUI is easy now
#175TUI may look good on the surface, but I’d really appreciate to see a good descriptive logs instead of a fancy progress bar
Re: Building a TUI is easy now
#176I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s…
What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore. I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.
I agree about the constraints. My ideal solution would also impose harsh constraints, but would also add just enough structure. I’m also frustrated by each app reinventing the same thing slightly differently.
Re: Building a TUI is easy now
#177Earlier quoted context omitted.
> I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. You'd think that, but you'd be wrong. Case in point from Emacs/Vim and the Borland IDEs to Claude, plus all kinds of handy utils from mc and htop to mutt. > They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web…
How many developers are using VSCode? How does that number compare with Emacs/Vim? In many ways, GUI was developed as the natural evolution of TUI. X server, with its client-server architecture, is meant to allow you to interact with remote sessions via "casted" GUI rather than a terminal. Countless engineers spent many man-hours to develop theories and frameworks for creating GUI for a reason. TUI just got the nosta…
I agree except about the TUI coolness factor. There really is a lot that’s appealing about TUIs, I agree on that with the other commenters here. I want a better synthesis than what we have.
Re: Building a TUI is easy now
#178Earlier quoted context omitted.
I’m definitely not advocating more little electron apps, and I’m totally with you on TUI’s benefits. I’m bemoaning the lack of imagination that has ended us up here and not in a situation where we can have, say, a small, low-footprint application that can deliver a more structured UI with minimal dependencies. It’s not an impossibility, it’s not even that difficult to imagine, we just don’t have the exact technology.
I think for the time being, there's no way to get around writing native UIs to get a native experience. Any sufficiently high level APIs will have to give up something. TUIs for me fill that niche because across any POSIX-compatible interface they will generally work the same, and modern high level languages make cross-compiling to terminals a breeze. Now to write a native UI across Windows, MacOS, Wayland and X11, t…
I’m happy to give up a lot; I’m not tied to fully-native-looking UIs for the types of things I’m talking about. Totally get that lowest common denominators will feel native nowhere. I just think it’s possible to do a lot better than the current state of TUIs.
Re: Building a TUI is easy now
#179I think TUIs-that-want-to-be-GUIs (as opposed to terminal commands just outputting plain text) are sad. Mainly because they’re largely inaccessible. They flatten the structure of a UI under a character stream. You’re forced to use it exactly the way it was designed and no different. Modern GUIs, even web pages too, expose enough structure to the OS to let you use it more freely. I get why people build TUIs, but it’s…
What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore. I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.
I don't quite agree with this. Feature discovery is much easier in GUI when most commonly used features are either in the first layer of menu or in standard hotkeys. In the worst case, you would do a search in GUIs that provide them. In CLI / TUI, no such function is present and you would basically have to man and scroll through all possible commands to find it, though I guess grep helps.
Re: Building a TUI is easy now
#180Earlier quoted context omitted.
What is great about them is the constraints they impose on the UI designer. I spend so much time finding actions in apps like Zed, Obsidian or Slack because menus and rows of buttons are not cool anymore. I'd really want explicit UIs from 2000, but in the mean time TUIs feel like an improvement.
I don't quite agree with this. Feature discovery is much easier in GUI when most commonly used features are either in the first layer of menu or in standard hotkeys. In the worst case, you would do a search in GUIs that provide them. In CLI / TUI, no such function is present and you would basically have to man and scroll through all possible commands to find it, though I guess grep helps.
You accept search in GUI, but don't in man pages? Scrolling through actions in a tree-like menu structure is ok, but through a tree-like structure in the --help output is not? Feels inconsistent.
The whole benefit of text-based interface is that search, filter and transformation is always available and completely independent of the running program.
I can see the visual discoverability aspect for GUIs, but for the visual layout GUIs and TUIs are on par, the difference is rather in the rendering mechanism: pixel vs. character-based.