I get it that maybe the constraints of terminals force design of TUIs to be more focused on the purpose of the tool than polish, but it's not that compelling of a point to me.
But the terminal is just fundamentally the wrong basic abstraction on which to build a structured GUI, it just happens to require few enough bits to be sent over the wire that it actually works reasonably well over SSH as opposed to pushing graphics.
Not only forwarding is trivial with Wayland, it also tends to provide better experience than X11 does.
Edit: yikes, pressing M-w caused emacs-pgtk to crash with a Wayland protocol error, so it isn't trivial and requires some configuring I guess.
Edit 2: Apparently I have to install wl-clipboard and write a bunch of emacs lisp to work around this. I don't think I have the patience for that, and I fear that such problems will be even harder to solve for applications which are not as flexible and programmable as emacs. So far I'll conclude that remote Wayland is not ready and stick to TUI.
Edit 3: No, the problem is probably mismatched waypipe versions on client and server. Still not fun.
I have used X11 tunnelling to machines on the other side of Europe and it was OK. I did prefer ssh for responsiveness. What happened to NX? What about other remote desktops?
That said for most tasks I would still rather SSH in and use CLIs (not TUIs).
I typically prefer CLI myself but having a TUI to manage torrents for instance was much more ergonomic.
https://developer.mozilla.org/en-US/docs/Glossary/Accessibil...
I am blind and do rely on accessiblity. But I would choose a TUI over a Web UI every day simply because the web is slow as hell. Feels like running away from a "monster" in a dream. You have rich details, but you are being drowned in unnecessary verbosity and an inherently slow stack of tools working together.
The web might be accessible, but it is barely useable in practice.
I'm curious which screen reader you're using and what can be configured to fix that experience.
* Virtual buffer: In most systems, the DOM is rendered to a "virtual buffer" and the screen reader lets you navigate that, because cursor (caret) support was on the map for accessibility, but was never really sufficiently implemented on the browser side. So screen readers had to solve it in a separate step.
* Using the keyboard to do screen reading and navigation on a site conflicts with keyboard shortcuts from that site. So most screen reader have two modes: You switch between entering text in a field and navigating/reading the site. Its basically like vi insert mode, but less simple.
Those are the major issues from my POV. The rest of the slowness likely comes from having to go through the accessibility API of your OS.
Like, okay, they are a big step back with accessibility, but they're flickering garbage because they were vibecoded in a weekend and the TS or Python library they're built on was similarly forced upon this world.
1. There's already a large-ish community of engineers who live in the terminal e.g. Vim/Neovim/tmux/zellij/etc users. Lots of engineering tasks are accomplished by running scripts in a terminal, so it makes sense for some people to just move as much of their work there as possible. This means there's a set of users you can address with dev tools that run in a terminal.
2. Cross-platform distribution among the platforms most of those people care about — macOS and Linux — is largely a solved problem via package managers. Distributing cross-platform native apps is fragmented at best.
3. Building modern TUIs has become a lot easier thanks to the demand+distribution wins above: there's a lot of appetite for building blocks, and so lots of good options have flourished like Ink for React, Bubble Tea for Go, etc.
4. General developer distaste for the most straightforward analogue to all of this for desktop GUIs: Electron. Deservedly or not it's associated with slow, bloated applications. And if you don't use Electron, doing cross-platform anything is going to be a much harder problem than just pushing out a quick TUI app.
Eventually successful products seem to eventually jump the gap, like Claude Code eventually spawning Claude Cowork and OpenCode adding OpenCode Web. But it's easier and faster to test product market fit for dev tools with a TUI. And plenty of your users will stay there, even after you launch something else.
I still today meet users missing those old workflows. But they express it as "old text interface" aka TUI. If you listen to them you realize they mean blazing fast and shortcut driven. When you work with data entry you care about speed - not animations.
Any beginner likes eye candy. The veteran has stopped caring.
If you're going to "run command, edit command, run command", performing the edits from the terminal you're running the commands in seems reasonable/intuitive. (In contrast, for tools like VSCode, I think it's more common for terminals to take up a fraction of the screen space rather than switching it to full screen. And then developers will say they need a huge monitor).
It also seems to be that keyboard-driven programs are more commonly TUI than GUI. e.g. magit or lazygit. Or lazydocker. Or k9s.
2) Constraints imposed by the terminal make all the apps look and work approximately the same - in the outside world the standards developed for UX are ignored as a matter of routine just because they can be. TUIs are in an optimum of least surprise, so to speak.
* Lower resource load * Less reliance on a mouse * Related: key bindings for more activities that fit my vi muscle memory * Deeper organization.
Thanks to TUI tools I've been able to roll my own IDE that's invisible when I need it to be (thanks guake & yakuake) and organized by project and tab (thanks zellij). For the mixed role I'm in that works perfectly.
I don't think anybody would look at what I have and call it polished though.
Ever used Emacs? Or Vim? Or Mutt? Or Borland's old IDEs?
The power of the terminal is also in ubiquitness, trivial connection to a remote system, and lack of mountains of GUI cruft, that a TUI app can as well have.
- CLI by default
- if I need a GUI, but no access to the local system: web
- if I need a (restricted) GUI with access to the local system: TUI
- else: either start a local web server, or, if nothing else works, go for a GUI toolkit
- you can use em over ssh
- they’re typically made with keyboard usage in mind, which is often an afterthought in a typical browser based UI
- other GUI options are browser (sandboxes, obvi, not good for lil personal tools), native (not dead simple, compared to TUI/browser/electron), or something like electron (no way lmao)
I don’t seek out TUI’s instead of other solutions. But it’s so dang easy to pop open a new pane and run lazygit. And it makes you look really cool when people walk behind you