My opinion is that TUI is just a GUI with less fidelity. Being composed of text characters provides no additional benefit other than a retro style. The benefits of the terminal are outside of TUIs - composing scripts, piping data, bash etc.
I do a fair amount of CAD so I'll use that example. Nobody who uses CAD professionally is clicking all the little buttons for tools. They're using commands, shortcuts, scripts, etc.
A GUI is slow and clunky. A textual interface, once learned, has way more degrees of freedom.
My two cents is that having all of your text be monospaced is not really ideal for agentic workflows where you do in fact read a lot of prose and in the future may want diagrams, rendered from a full browser's capabilities, etc.
I think I like the aesthetic of using a TUI because it makes me feel more like whatever 'real programmer' means to me... but I recognize its also cope.
(Also TUIs made a lot more sense when code was more expensive, because the monospacing constraint made it faster to build UI, etc.)
Yes, power users often use shortcuts and automation, but how is that an argument against GUIs?
It simply depends a lot on the actual task. Certain things absolutely require a (high fidelity) graphical interface. Other things can be done just as well (and with less distraction) in a simple TUI. You can't generalize.
TUIs compose with tmux. Pi's homepage says "use tmux" twice on it. It fits right into an already-mature ecosystem including a clipboard (powered by Vim visual / line / block mode) and easy integration with shells, editors, and other tools. GUIs generally have to re-invent all those wheels (tabs, splits, sessions, etc.) and it never integrates as well with other tools in a totally cross-platform way.
GUI scripting is still not a thing today. That's the biggest issue with GUIs.
Plus the mouse is genuinely bad for ergonomics.
Plus if you type _fast_ then TUIs are a great starting point.
Plus what's the equivalent of scrollback for a bunch of mouse clicks?
Plus TUIs are much more I/O efficient, which means running them over ssh/mosh/whatever is a great option.
Plus the shell is a programming language -- the GUI isn't just hard to macro-record/script: it doesn't even have a programming language you'd use for that.
Cursor has this, and there are others that can attach to ssh or open their UI via a tunnel or web interface.
SSH is mighty convenient though, so I am not necessarily saying your point is incorrect.
I hardly use anything aside from neovim and a browser. (okay corporate Mattermost fork and video terminal too).
For me switching between different cli\tui tools feels like a continuation of whatever I was doing, while going to something GUIsh is not.
And to be honest: what do you even need from a harness\agent for it to have a gui?
Oh, it's just so much nicer! Personally I'm a graphics/typography nerd, so just having nice fonts, smooth movement, use of sizes, colours and graphics to differentiate and display types of information... Some people obviously don't care about this kind of look and feel nicety, but even so a GUI has so many more opportunities for displaying information in a clear but dense way.
They can even show images these days.
Some of the elements can't be recreated 1 to 1 ofc, like borders with delicate margin\padding adjustment, but this is about it I think.
To each his own, yeah. From my experiment GUIs tend to overcomplicate things and display too much info you didn't need in the first place.
experience
The native format of LLM interactions is markdown, and showing that in a terminal is a poor imitation of what it looks like rendered properly.
An interesting thing you can do in juggler is ask the LLM to reply in HTML instead of markdown, and they can then do things like illustrate points visually for you. LLMs are actually great at being able to express things visually to the user, but being stuck in terminals so much, people haven't really leaned on that very much
Nothing absolute that I couldn't live without. But TUI is essentially a design written for the lowest common denominator. It doesn't matter that I have had high resolution displays for years, average TUI is designed as if I'm using computer older than me.
I love the terminal for terminal things. I'm not convinced agenetic coding is best implemented in a terminal - for it to work well, you're basically reinventing a toolkit wheel. Why not just use a nice graphical toolkit? It feels a bit like the current trend for pixelated graphics - both retro and worse.
I love good GUI apps. They are hard to do well.
Juggler, for example, already collides with a Keyboard Shortcut I use across the desktop, so CMD + J can't be used. It also uses CMD + / for keyboard shortcuts? Tha's a choice. It doesn't respect Mac's preferences/settings shortcut (CMD + ,)
You can be on a chat window, and there is no way without using the mouse that I see where you can start typing into the chat box. Juggler tells me to type / and I can run a command. I type / and nothing happens. What that really means is I have to use my mouse to put the cursor in the small chat box down below.
This isn't to say Juggler is bad. Rather, it's got a long way to go for the GUI to be something that has the fluency of something like vim.
TUIs generally have to solve for that. You have to offer up those features. You can't rely on laziness. So at the very least, there generally are keyboard shortcuts and they need to be obvious.
Feel free to think that people don't have a rational reason for TUIs, but it buys you a lot for free. And this isn't an indictment on Juggler. It works. It's functional. It doesn't feel natural, nor does it respect conventions.
I've never felt that urge, I've always been happier using Visual Studio / Xcode / VScode with default key bindings, and focused on other things. I'd rather click things inefficiently with a mouse than invest effort learning keypresses. Neither of us are wrong or right, but I think I'm trying to cater for my tribe on this project!
> I totally get it. Lots of people, like you, love to set up their perfect custom, key-driven environment, and tune everything just how they want it.
No, you don't "get it." Like me? I don't want to set things up. I don't want to customize. I thrive off convention. And there are apps that follow these conventions. They do this out of respect for people who enjoy the defaults they enjoy elsewhere in other applications.
> I've always been happier using Visual Studio / Xcode / VScode with default key bindings
That's not true though, because you don't even use the same default/convention key bindings they use. By doing things your own way, you are making it so it's harder for your users to adopt your application.
> "mine does that too, but with lovely graphics.",
But it doesn't. You don't care about the little things, so how are you going to get the bigger things correct?
Listen, it's great that you built a tool that you love. I love doing that, too. But if you want users, you have to respect them. And that means making it easier for them to use your app.
And if our app just doesn't work because / doesn't do what it says it's going to do, that's an issue. And if your app doesn't allow for customizing keyboard shortcuts, it's disrespecting users who have those set for something else.
> but I think I'm trying to cater for my tribe on this project!
Just realize that tribe is juggler-ai users, or people who don't use defaults. People who are fine with default key bindings, can't effectively use your app.
I wish that was true!
I'm not a cowboy arbitrarily making up random shortcuts. A major goal here is for a user to get near-as-dammit the same UI in a desktop app and in a remote browser. So all these shortcut choices have been a compromise between:
- what different people might expect the default to be (on mac/windows/linux/all kinds of apps)
- what a browser already uses (on mac/windows/linux/chrome/firefox/safari/etc)
- what people might have overridden random window managers and custom OS shortcuts
- what tasks are common enough that they deserve an easy-to-reach/remember key in spite of other factors
- choosing groups of shortcuts where you want the keys to be related (e.g. navigation) despite some being taken on some platforms
I obviously want the least surprising UX, and if this was just an app on one platform, it'd be easier. I've had to build a multi-platform shortcut manager that changes depending on the client, while trying to also keep as many as possible constant.
And yes, allowing users to customise the shortcuts is obviously on my list, but a) I wanted to let the app settle in and make sure I've got the right data model for storing key shortcuts first, and b) other more urgent features..
BTW `cmd+/` is the default "show the key shortcuts" in most chat environments like discord, slack, teams, google docs etc. These are much more relevant to juggler's UX when it comes to default shortcuts than things like VScode!
(...but yes, I had forgotten to add a desktop-app-only binding for `cmd+,`, so thanks for mentioning that - I've sorted that out now..)
How can a GUI replicate this workflow? I know it could, technically, but not as easily.
Pi is a great project, and people love it for good reason, I have nothing negative to say about it or its fans. I'm just trying to do something that appeals to the more GUI-oriented folks. And yes, I'd really love to know if there's something that's making people bounce off the product, because it may be trivial to fix!
You run it on some headless machine, and point your browser at the HTTP server it creates to see the full GUI. It uses Yjs to make that connection as efficent as possible, and it works great.
The desktop app is literally doing the same thing internally - it runs a headless server process and serves the GUI to its own window. But you can stretch that over a network and it's the same experience.
I can even connect to it via a TURN server, from my phone on a cell signal, and although it's not as snappy as running locally, it works pretty well.
And, of course, most of the tools have created their own GUIs anyway, which are far worse than VS Code (even when they've forked VSCode itself!)
I think the "borderline psychotic" phrasing is apt.
Wut?
For an example, see my MSPaint drawings in the README (scroll near the bottom) for this tiny little project: https://github.com/rspeele/meshorient
I redrew those for the README but IIRC, I drew something similar when explaining how the feature would work to the agent.
And in reverse, after describing an architecture or an algorithm to it, I'll sometimes ask it to draw a diagram for me to demonstrate its understanding. If it draws the picture in line with what I intended, I conclude that it has gained the necessary context to proceed. If not, I know I explained something wrong or at least insufficiently and need to provide clarification. There are some domains where a picture is worth a thousand words.
It also helps cut through the Claudese. "Your decision is needed for one edge case, found by the gate. When a T-joint meets an endcap that the mesher solves by a fan, should this bisect a fan slice or raise a warning?" I'm sorry Claude, I am not from Missouri but you are going to have to Show Me this one with a picture.
Of course you can save pictures to files and open them with external tools, but it's nicer to have them inlined into the chat history when that's exactly what they are: part of the conversation.
And in juggler (and probably other harnesses too) the LLM can reply in HTML. So if I'm planning e.g. some UI changes, I might ask it "show me what this button will look like" and it'll reply with a picture of that thing in its response. No temp files to open or clean up, and fewer tokens burned