I hope vibecoding doesn't mean the concept of contributing upstream gets lost. At least some of this (mouse clicking) would have been a great upstream contribution instead of rewrite.
I wish we had a "cool" GUI toolkit. GUIs are way better at this stuff. Adding point and click is so close to being a GUI, the only possible reason this is a TUI is fashion.
Idk if you are managing k8s stuff you are probably in a terminal already. Staying in a terminal is nice. Plus having persistent multiplexer sessions is a big deal in locked down corporate environments.
Most common things power users seem to want from TUIs on desktop:
- Easy efficient remote access. Pixel streaming and things like GTK Broadway are out. Needs a proper protocol/standard that would send styling-neutral primitives (and that is not X11 forwarding), and the entire toolkit architecture built around that. Something like SPICE/QXL but more semantics-aware? Maybe too low level but why not.
- Staying in the terminal. This is a matter of window management, though a toolkit can offer good defaults so this doesn't feel janky.
- Keyboard-first. Trivial. "GUI is for filthy mouse casuals" is a ludicrous idea.
- Low bloat. Web and things like GTK Broadway are out.
I haven't seen two similar opinions on actual architecture and stack, however being available in Rust will be a great start.
I guess like a TUI, since that's what is deemed to be cool. I don't decide what's cool, I'm just an observer.
Imagine something that looks cool like a TUI, but has pixel perfect graphics and typography where useful, is as fast and functional as Windows 98, but is still tiny, and can be entirely keyboard driven if you prefer that (which I do). We can have all of this today.
How are GUIs "way better at this stuff"? I can't see it, but would like to understand how you feel that a GUI can improve on the management of automated processes at scale.
Just one example of the top of my head: filter by labels, sort by name, select a few pods using ctrl+click, view logs. GUIs were super quick at this sort of stuff in the 90s. I use kubectl myself, but when I see stuff like this it really seems like people just want GUIs again.
There's two different levels to this imho, a tui is usually still a non-bloated self-contained binary that can run on windowless server envirorments just fine.
TUIs can have GUI like affordances UX/UI wise regardless of if they use the terminal as the contract or a window server/gui lib
> a tui is usually still a non-bloated self-contained binary
A GUI app could be a non-bloated, self-contained binary too. There's nothing intrinsic to GUIs that prevent this. TUIs are, after all, just GUIs that use text characters instead of pixels.
> that can run on windowless server envirorments just fine
Who cares? Who runs without a graphical window manager? Kubernetes is from the ground up a network application. The entire point is you don't SSH into nodes any more, you run management tools from completely separate computers that have window managers. The fact you can run stuff like this in a text console is nothing more than a novelty and a curiosity in 2026. I guarantee almost everyone running this will be running it in a terminal emulator in a WM.
> TUIs can have GUI like affordances UX/UI wise regardless of if they use the terminal as the contract or a window server/gui lib
Yeah, but it's slow and cumbersome compared to a GUI and it's an incredibly inefficient use of the thousands of pixels available on a modern screen.
The code generated by Claude is fully under my control, and I make sure it works exactly as I intend. I could have hidden this by committing it myself, but I choose to acknowledge that I had Claude's help
The Claude-generated README doesn't inspire confidence in that. I believe you checked all the code, but a lot of people are going to see that README and not give the project a second chance.
But now other people's code is just a starting point for me forking an app to do exactly what I want it to - it's inspiration because code is cheap.
Of course for larger projects we will still need solid components underlying them, but what you're really talking about is just maturity - it's very easy to produce a lot of output now but you can't replace actual history or having more then exactly 1 maintainer.
Jokes aside, Opus 5.5 and Fable 5.1 are on another level. I was recently vibe coding an app, and after three days of prompting or so: sigh “I need to bite the bullet, and finally face the slop” — I started to read the code, and to my surprise, it was adequate. Not an amazing code, not a slop either.
I cleaned it up in one session. 50k LoC of Golang. Although even language is less important nowadays. People make DSL, and LLMs immediately start programming on this DSL.
I don't care about clicking into the terminal. I don't understand why people do this more and more.
You just need to use your keyboard shortcuts correctly and navigate the tmux/kitty session as it's intended to.
See that's all a matter of workflow? You don't understand it because it's just not for you
Actually, I’d really like to know the answer to this. I’m not a fan of clickable TUIs. Mouse events in my terminal are one of the banes of my existence.
But, if they are more popular with others, that would be helpful to know.
It might be different if these things leaned a little bit into acme - or at least had some justification for what was similar and what was difficult. Like; do you want to be a powerful text-oriented tool, or just a nostly-dumb print out?
There are reasons for both - but ignorance shouldn't be one.
A clickable TUI is contrarian to why I use most CLI tools. Neat that they could build this, though, because it suits their needs.
I'm fine with K9s and lazygit key-driven interfaces.
I guess one thing that's good about a clickable TUI is that maybe it's easier to approach for some, wihtout releasing yet another memory hog Electron App?
Some of us enjoy working entirely in the terminal. It’s OK not to enjoy that, but I assure you, I am far more productive in tmux + nvim than in, say, VSCode.
I'm really surprised that "clickable tui" is grinding so many gears here. I've been using Linux for over 20 years. I love a good ol TUI. But nothing about clickability precludes a TUI from being useful. I love mouse support in tmux, for instance. I can shift-arrow my way around windows but I can also just click one (or tap one, if one a touch device). I do this all the time when controlling tmux from my iPhone. Why is this such a bad thing? It makes zero sense. Judge this tool on its merits of being a TUI for interacting with Kubernetes... not because it allows mouse input.
48 comments
[ 9.0 ms ] story [ 51.3 ms ] threadI appreciate the tui.
- Easy efficient remote access. Pixel streaming and things like GTK Broadway are out. Needs a proper protocol/standard that would send styling-neutral primitives (and that is not X11 forwarding), and the entire toolkit architecture built around that. Something like SPICE/QXL but more semantics-aware? Maybe too low level but why not.
- Staying in the terminal. This is a matter of window management, though a toolkit can offer good defaults so this doesn't feel janky.
- Keyboard-first. Trivial. "GUI is for filthy mouse casuals" is a ludicrous idea.
- Low bloat. Web and things like GTK Broadway are out.
I haven't seen two similar opinions on actual architecture and stack, however being available in Rust will be a great start.
Imagine something that looks cool like a TUI, but has pixel perfect graphics and typography where useful, is as fast and functional as Windows 98, but is still tiny, and can be entirely keyboard driven if you prefer that (which I do). We can have all of this today.
A sibling comment has shown a GUI toolkit that I think would be considered cool: https://news.ycombinator.com/item?id=50010671
we need more experiments with X11 interfaces
Imgui is also good for this
TUIs can have GUI like affordances UX/UI wise regardless of if they use the terminal as the contract or a window server/gui lib
A GUI app could be a non-bloated, self-contained binary too. There's nothing intrinsic to GUIs that prevent this. TUIs are, after all, just GUIs that use text characters instead of pixels.
> that can run on windowless server envirorments just fine
Who cares? Who runs without a graphical window manager? Kubernetes is from the ground up a network application. The entire point is you don't SSH into nodes any more, you run management tools from completely separate computers that have window managers. The fact you can run stuff like this in a text console is nothing more than a novelty and a curiosity in 2026. I guarantee almost everyone running this will be running it in a terminal emulator in a WM.
> TUIs can have GUI like affordances UX/UI wise regardless of if they use the terminal as the contract or a window server/gui lib
Yeah, but it's slow and cumbersome compared to a GUI and it's an incredibly inefficient use of the thousands of pixels available on a modern screen.
I appreciate the effort. May I ask how do you tackle this?
But now other people's code is just a starting point for me forking an app to do exactly what I want it to - it's inspiration because code is cheap.
Of course for larger projects we will still need solid components underlying them, but what you're really talking about is just maturity - it's very easy to produce a lot of output now but you can't replace actual history or having more then exactly 1 maintainer.
Jokes aside, Opus 5.5 and Fable 5.1 are on another level. I was recently vibe coding an app, and after three days of prompting or so: sigh “I need to bite the bullet, and finally face the slop” — I started to read the code, and to my surprise, it was adequate. Not an amazing code, not a slop either.
I cleaned it up in one session. 50k LoC of Golang. Although even language is less important nowadays. People make DSL, and LLMs immediately start programming on this DSL.
When Claude added it, I immediately hated it since you click into the terminal and accidentally click something.
Or can we do it with a cli wrapper process?
Actually, I’d really like to know the answer to this. I’m not a fan of clickable TUIs. Mouse events in my terminal are one of the banes of my existence.
But, if they are more popular with others, that would be helpful to know.
There are reasons for both - but ignorance shouldn't be one.
https://9p.io/wiki/plan9/Using_acme/index.html
Why is this a good thing? Have a help you your access via ? and document what the keys are. Don't dumb the interface down.
I'm fine with K9s and lazygit key-driven interfaces.
I guess one thing that's good about a clickable TUI is that maybe it's easier to approach for some, wihtout releasing yet another memory hog Electron App?
Of course with all the running around with AI programming, it would be nice if we could task sometime to making remote desktop not suck on Linux.
Claude code uses react, iirc
It seems we cannot move on from them and I think we should.
It is a shame because surely there must be something better than terminals and TUIs.
https://github.com/nklmilojevic/sofka
That's the actual k9s successor imho!