alt Hacker NewsAs a ratatui library maintainer, NO - please don't stop making TUIs ;)
As a developer outside of that, I love the scratch the itch apps stuff mentioned in here. I have a vibe coded SwiftUI chess repertoire builder app that fits in that same sort of space that I'm currently working on, where I'd probably not have chosen to explore the idea if not for coding agents.
I agree with the article that the terminal is an odd shape which you're fighting against historical specs, etc. The key observation I have though is that the mismatch of terminal apps and libraries to deal with this are all fundamentally built around character cells and cursor movement plus various CSI/OSC/ASC/DEC/xterm/... protocols which are complex and have varying support and interact in weird ways.
To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc.
I know Mitchell Hashimoto has a bit of a different perspective on this, which seems like it's to define some more protocol stuff and continue to build up on things. I think that probably gets to 95% pretty well. But a 100% good is a full replacement.
Replies
Ratatui is such great work.
The New Terminal, the complete break from VT100, is I think the most powerful rebuttal to what I'm saying about TUIs.
My take is that the Morlocks should pack everything that is great about TUIs (and there are great things about them) and move them upstairs to live alongside the Eloi in GUI-land. Let 1000 Bloomberg terminal interfaces bloom.
But there's another even more ambitious take on this, which is to take everything that's pleasant and good about Eloi world and bring it down into the Morlock caves. I don't think you can accomplish that so long as you're drawing interfaces with punctuation characters, but there's nothing to say a terminal has to work that way; you can have a terminal with rich out-of-band-signaled UI. Not just, like, Kitty graphics, but something more like a real terminal that is meant from day 1 to work with all the complexity of a Bloomberg terminal.
You could have had it in 2010, but it's a king hell mess to put together, and you'd sort of assume nobody was going to use it (because it's a break from VT100 compatibility). But that doesn't matter anymore! We are the music makers, &c &c.
I think a lot of very smart people assume we're going to build up from VT100 to something incrementally but significantly better (Ghostty is already materially better than anything I'd used prior). But I hope those people eventually set their sights higher.
Grok Build uses your library and it has the best TUI of any app I've ever used. It has a lot of features that we take for granted in GUIs like scrollable regions, buttons, collapsible panes, and text selection.
I don't know why Codex and Claude Code haven't switched over; both apps have a terrible UI in comparison.
I have a question - I've briefly looked at the API, and it seems like a mostly general-purpose user interfance library.
What do you think of replacing the 'render' part with something that's more like a generic UI? You could keep the UX the same, yet your app would look like a desktop app (or at least close to it).
Trying to fit in the limitations of 80x25 text rendering is cool, but there's nothing in the underlying architecture that of modern graphics display that's predisposed to that, it all ends up as GPU commands.
I'm sure you could get most of the way to what I'm describing with just replacing the font/character set with one that renders things like borders in greater detail.
Hell, you could even add this as post-processing. You look at the terminal output with cellular automata like rules, and try to render UI primitives fitting that.
> To get a good terminal UX, ...
At that point you're just inventing a new DOM variant and aren't fundamentally different from any other opinionated GUI framework. The value of the terminal for me is the minimalism. I absolutely despise all these new "features" that get added via protocols. I _want_ the boring grid composed entirely of extremely primitive character cells where WYSIWYG in terms of any underlying abstraction. The only innovation I welcome in this space are improvements to portability and speed.
My snarky response to the author's title would be that you can take your GUIs and all the janky flashing lights they entail and shove them up your ass.
I’ve found some of my favorite TUI apps by scrolling around in the built-with-ratatui page. I have always bounced off of rust but ratatui must be a great library!!
Damn, what an epic library name.
Not only I want people to stop making TUIs, I want you to stop maintaining your TUI library!
The approach you're describing (redesign the protocol) is one path. Another is to sidestep the protocol entirely by using a platform that already owns its rendering surface and happens to run in a terminal: my preference is Neovim.
Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, you're just buying another learning curve. Also, the language is Lua (not Rust) so it won't appeal to the ratatui crowd on that front, and there's no proper layout system yet.
Neovim [0] renders to its own buffer system (extmarks, floating windows, virtual text) rather than emitting ANSI escape codes. Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box.
On the UI framework side, morph.nvim [1] provides a React-like component model (h(), state, reconciliation) on top of Neovim. It's not a general answer the way ratatui is, but for the slice of devs already in Neovim (there are dozens of us!), it's a pragmatic way to get GUI-framework-like ergonomics without the terminal protocol fight.
For a sample of what TUIs in this paradigm can look like, I've been working on tuis.nvim [2] (Docker, K8s, SystemD services, process management, and more all as native Neovim buffer TUIs).
> To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc.
Why not just… a GUI framework or layout that’s meant to be keyboard driven and information dense?