Hacker News Reader

Hacker News

Comment by bluegatty | Hacker News Reader

Parent Full thread

bluegatty

""GUI is less verbose with the nitty gritty hidden in expandable sections, ""

? The GUI has nothing to do with that.

If you use Chat / Work / Code <- that's the differentiation.

So 'Code' in 'Gui' is identical to Claude Code except for the visual layout.

If you use Work or Chat, which are not optimized for Coding you'll see a different experience.

If you use iTerm or Ghostty and set a key combo to switch tabs you can very easily switch between tabs and the TUI generally gives more dense information.

Usually people migrate to TUI not the other way around.

I think that there are reasons to use GUI - if there is deeper integration with Git or an issue tracker - or - in VSCode - for navigating files etc. - definitely those things are valid.

But for raw AI the getting a TUI to work the way you want it is ideal.

View on HN

I don't get why people love TUIs so much. They're basically GUIs made using inferior tools. Why hammer in a nail using your fist if you have a hammer handy?

A GUI is strictly more powerful than a TUI (because a GUI could just show plain text in cases where that is the most appropriate mode of interaction, E.G. Bloomberg, AMadeus), but it could also do so much more in cases where it is not.

I do love terminals, don't get me wrong. When what you're interacting with is CLIs and Unix tools in a shell, a terminal is exactly what you want. I do love the Unix philosophy, I like small and composable tools that you can use together, and I think the interactive way of working that a shell or REPL can give you is great (though notebooks would have been better, but that's beside the point). Those are things that the terminal shines at. Pretending to be a GUI is not one of those things.

A couple of reasons

1. Lower resource consumption (ram, binary size)

2. Usable over the network (ssh)

3. Often much easier to drive with automation software (agents/scripts)

4. Ui tends to be dense, matches your font perferences

> 1. Lower resource consumption (ram, binary size)

Have you used Claude TUI? :-)

> 3. Often much easier to drive with automation software (agents/scripts)

TUIs? Not really. TUIs aren't composable, CLIs are. Now, many TUIs also have a separate CLI mode built-in, but guess what, many good GUIs also have a built-in CLI.

TUIs are also frequently harder to automate via click-click than decent GUIs, since mature GUI toolkits tend to have built-in accessibility and I doubt anyone has ever programmed extra accesibility into any TUI in history, outside of the default keyboard access they get because they're inherently character driven (though that can take you quite far).

Many TUIs break even basic UI composability stuff like copy/paste; accessibility is even lower down the list.

Are you saying I should go back to GUI? I just feel it’s so awkward. I have LazyVim for more advanced review, Hunk, etc… the GUI is like a inferior version of Eclipse IDE or something. Or it used to be, atleast.

I love the terminal.

I live my life in the terminal.

I use lazygit all the time. I integrate delta with it.

But I use vscode GitLens for diffs.

I always find the view port in lazygit to be too narrow. My feeble brain cannot work with so few context.

You and me, bro. Look at this diff plugin for nvim, so pleasant. You’ll avoid vscode

https://www.reddit.com/r/neovim/s/3AyZ4NSBMz

It's because you can ssh into something and VNC sucks.

GUIs are great when you're sitting in front of the computer it's running on. Trying to do anything remotely with them is terrible. RDP is pretty great at making that experience suck less tho.

Ironically, remote work is the main thing I use Claude Desktop (and mobile) for. When I work locally, I’m usually happy with the TUI, unless I need a lot of equations or images. When I work remotely, keeping the SSH connection alive or juggling tmux sessions is too much of a hassle, and running the remote session from Claude Desktop/mobile is more comfortable.

Claude has a killer feature for me with that remote-control command.

Spawn a Claude TUI where you need it and take remote control with no friction.

I tried it in codex and they messed up the flow so bad. You need to add a device oauth token every time you set it up even though it's already logged into your account.

Just a heads up, I build Cosyra, a mobile terminal app, so this problem is something I've been considering a lot. For the SSH side, mosh fixes most of it. And for the tmux sessions I use a leader terminal who does all the juggling for me. Remote control is great, but then I'm completely locked into using Claude which, for me, does not work.

Have you heard about sixel or the kitty graphics protocol? I. what makes me a terminal terrorist, I've got an adaptation of cat on my GitHub where you can cat an image in the terminal, and if you're using a modern terminal, it'll display the graphic.

One benefit is that they're easy to use remotely over SSH or in a VM, but I agree that a local, native GUI is generally better than a TUI.

You can use VSCode over SSH as well.

You can but with agents you might want a security boundary/faux-airgap between the agent and your machine. I don't think you should trust X11/Wayland forwarding to maintain strong isolation against a malicious server in that scenario.

TUIs are superior in that case because they cuts the attack surface down to a regular SSH session.

Agreed. I sandbox agents using containers which also allows me to inject credentials and all sorts of things.

I think there's 2 clear layers in these coding tools: the runtime engine that lives ON the system, can execute commands, read/write files, make network calls and the UI, which can be a local (TUI) or remote.

A remote UI allows you to manage multiple remote runtimes concurrently and can even be on your phone.

Anyone preferring Desktop vs TUI is not managing multiple systems I would guess.

Personally the Claude Code TUI also sucked every time i used it. Scrollback bugs in IDEA embedded shells, extraneous output vs the VSCode extension, and unreliable links to source code.

Isn't the CC TUI written in React?? I mean my web dev "all i have is this hammer" brain is intrigued, but surely, there's better things to do? Like you said, the terminal is great for piping inputs and outputs, for scripting, for bulk operations. It's really not great for real time interaction across many files, which is how i use CC and kind of wonder how you would use it any other way. (I guess if you literally just prompt and pray, the UI literally doesn't matter?)

Terminals are 'activity dense' and usually have a lot of key cusotmizations.

You can't even have 'tabs' inside of Claude Desktop, which is a dealbreaker for most power users.

Most GUIs are designed in a way that I dislike. It’s true that terminals lack power compared to GUIs, and some GUI apps (Bloomberg, Blender, …) are reasonably well designed for their use case, but most GUIs are such a disaster that it’s almost more fun interacting with them via curl to an API or SQL directly to a database.

The other problem is that all the GUI apps look different. I really want one extremely powerful, composable GUI “framework” that all apps sit within. Ideally I could even decompose and recombine parts of different apps into new tools or workspaces.

Now that anyone can build a GUI by prompting LLMs, maybe we’ll get actually good GUIs, or at least be able to build our own, but up to now the direction of travel has been disappointing to say the least.

Most agentic UIs are structured exactly the same regardless of the interface. TUIs are not composable in any possible meaning of that word (unlike CLI/REPL), they are GUIs on a fixed cell grid. Real TUI aren't unified either.

They are rich TUI but they remain somewhat scriptable environments. From the plain claude -p to run Claude code unattended, all the way to setting up hooks, MCP tools and injecting key presses. Complex and hackish yes, but probably not worse than attempting to automate fully GUI tools like Claude desktop which is meant to automate stuff, not the other way around.

All that is completely UI-agnostic and not related to GUI/TUI distinction in absolutely any way. Keypress automation is terrible, if you have to resort to jank like this you'd better use something like AT-SPI (which no TUI implements) or at least DOM manipulation and userscripts on web, although I've never seen a use case for that, sanely designed agents are malleable enough to avoid it.

The point is that I agree with the OP, terminals are fundamentally unfit for applications like agents that are not REPL and need complex interfaces. All attempts to fit them into it I've seen are 99% cargo cult, like the entire TUI zoo that keeps layering the cruft just because people are culturally averse to clean first-principle designs or put pretentious "aesthetics" first. Just look at the amount of misconceptions voiced ITT. This incidental complexity is destined to snowball into web/Electron-like Rube Goldberg machines pretty fast, and I guarantee you will hate it. It's already spinning out of control with agents.

I suspect that this is what Mitchell Hashimoto is up to with Rex and Superlinear.

Because a minimum viable GUI is way worse experience than a minimum viable TUI. Also GUIs take more skill in order to feel performant, which many companies do not possess (just look at various documentation webapps that take >100ms just to navigate between really simple mostly-text pages. Horrible).

Good GUIs with full keyboard functionality are definitely better than TUIs though. There's just no guarantee that some solo dev'd GUI for a brand new workflow can meet that standard.

Reply on news.ycombinator.com