Ratatui – App Showcase
Posted2 months agoActiveabout 2 months ago
ratatui.rsTechstoryHigh profile
excitedpositive
Debate
20/100
RustTuiRatatuiTerminal User Interface
Key topics
Rust
Tui
Ratatui
Terminal User Interface
The Ratatui showcase features various TUI applications built with the Rust crate, sparking interest and discussion among HN users about the potential of TUIs and Rust.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
56m
Peak period
115
0-12h
Avg / period
22.9
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Nov 5, 2025 at 9:50 PM EST
2 months ago
Step 01 - 02First comment
Nov 5, 2025 at 10:46 PM EST
56m after posting
Step 02 - 03Peak activity
115 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 12, 2025 at 11:59 PM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45830829Type: storyLast synced: 11/22/2025, 11:17:55 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Charm would probably say the same for Go.
SSH apps serve a similar UX to web apps which I just think is a great idea for many use cases. Needing to install a cli tool just to upload some files is tedious when you can just use rsync, sftp, piping, or even sshfs
A fun example of this is https://www.terminal.shop/
Submitters, please remember this from the guidelines:
... please use the original title, unless it is misleading or linkbait; don't editorialize.
The only places I know of is Awesome TUIs [0] and terminaltrove [1]
I can also see that Ratatui has an awesome list too [2].
[0] https://github.com/rothgar/awesome-tuis
[1] https://terminaltrove.com/
[2] https://github.com/ratatui-org/awesome-ratatui
[0] https://github.com/NimbleMarkets/ntcharts/blob/main/examples...
[0] https://en.wikipedia.org/wiki/Turbo_Vision
We just don’t have good desktop GUI platforms anymore. Qt and GTK are massive beasts, Windows changes theirs every 4 years (and no one wants to be tied to a single platform anyway), we don’t want to deal with Electron, and writing your own GUI from scratch is hard.
Terminals just got good lately and it’s way easier to make something higher quality in them than as a GUI. It’s just too hard to make a good small desktop app.
It’s the same reason why it’s easier to make something look great with LEGO than if you want to mold clay. I’d also wager that devs today on average know more about good UX than devs did back in the 80s when clunky terminal apps used to be made.
Buttons are a good example. If you want to define a button theme, you have to individually define the theme for every possible state the button can be in. No inheritance, the best you can do is copy and paste them over (which means if you want to tweak one, you have to tweak them all). Compared to something like CSS, its a nightmare to theme even slightly interactive Godot GUI's
Another homegrown personal tool I had once written was in Go with DearImgui, so basically with AllenDang/giu... also really quite rapid dev and lean-enough binary / perf.
But Godot is wysiwyg for GUI stuff, so that's a plus..
I believe this might be current most popular application using this library.
I'm surprised it isn't included in this showcase
I used codex to write the VHS script, which runs codex to generate a Ratatui app, and then then used codex to add this to the website. It's codapodes all the way down.
A few reasons:
- for the most part TUI apps are cross-platform: macOS, Linux, BSD, Windows
- they cut down on context switching. If you're already in the terminal, you shouldn't have to switch to a GUI app to check on something.
- Today's terminal emulators—Ghostty, WezTerm, Kitty, iTerm, Alacrity, etc.—are fast and capable with GPU acceleration, 24-bit color support running on high resolution displays. It makes for a compelling platform to code for.
- Anecdotally lots of developers are spending less time in IDEs and more time in the terminal using Claude Code, Gemini CLI, Codex, etc.
This means almost all TUI programs can be entirely keyboard driven.
Almost all GUI programs fail at this, in other words, it's extremely likely that at some point, something that requires a mouse action will interrupt.
For me, often, it’s an escape for a GUI world taken over by out-of-control “design” tenets. I value good Ux design concerns, but often working with designers lately feels bureaucratic, at times cargo culting, and overly spacious.
It’s like a graphical form of “I didn’t have time to give you a short answer, so I gave you a long one instead”. TUIs force a paucity that often makes for a nice information/pixels ratio.
I for one love the tranquility of a dark mode terminal and find it quite pleasant with a nice nerd font, a pretty color scheme, a single high resolution monitor and an ergonomic keyboard. I feel much more connected to the code or data I’m interacting with in that space. Trying to live there as much as I can lately. JiraTui has been great for preventing context switching at work.
When Rust came along and presented a career opportunity, terminal apps was a great way to get into it and filled a gap in a lot of people's skill sets. Even when building GUI apps in Rust, your first entry point is a CLI usually.
We took our UX thinking from web & mobile and remixed it with Rust and new ideas came out. Turns out "If it aint broke don't fix it" for two decades can build up a lot of evolutionary pressure.
Meanwhile, distributions sometimes maintain their plodding rate at package updates (usually handled by distribution volunteers, not the original program's developers), which was developed in an era when building from source was a tedious process where the distribution volunteers provided value.
In effect, build-from-source has taken over "just use the distribution package".
EDIT: Which is what I'm doing right now for a few of these that caught my eye.
And in the Unix world, build from source can be pretty easy. When it’s hard, it’s usually the project’s fault (Firefox, Electron,..).
Not in the real world, where most of the useful software is not in fact written in Rust, nor Go for that matter.
I starred Posting[1] but haven't yet got around to trying it.
[1]: https://news.ycombinator.com/item?id=40926211
Edit: here's another one: https://github.com/LucasPickering/slumber
With the path they've chosen, it may mean less version churn, but the other side is you've gotta wait for each widget author to upgrade their widgets when Ratatui upgrades. This can lead to a situation where some widgets upgrade, some don't, and you're left either on the lower version with unpatched issues, or the newer version missing widgets.
I much prefer the design of web-sys and js-sys, where all the features are included and gated behind feature flags.
We're fixing that in Ratatui 0.30 by introducing a stable core crate.
Is anyone working on this?
With the speed terminals are and support for graphics through things like sixel and shaders I'd love to have a browser even if I couldn't do videos. Even if it was like viewing most pages in reader mode.
I'm not sure some big companies would be happy about that though since it likely would mean you could do things like ad blocking more easily. But maybe you could get them on board if you pitched it as a browser for LLMs. Something something it's a native interface for them. ;)
I know there's some browsers but things like W3M, Lynx, or *links* are... rough... definitely not of the quality we're seeing elsewhere in the current TUI revolution.
You can already do this, since the 90s: Lynx[1] and w3m[2] have both existed for more than three decades at this point.
[1]: https://en.wikipedia.org/wiki/Lynx_(web_browser)
[2]: https://en.wikipedia.org/wiki/W3m
https://github.com/rkd77/elinks
I sincerely hope it isn't the reason though, I'm a huge rust fan myself (10years of coding with it already) and I think rust is definitely the future, but that doesn't mean all previous open source foundations should be thrown away.
I mentioned those by name...
This is enormously better for UI response time and things like compressed files: you only transfer the compressed text, image, audio, or video files rather than the decoded form which can be an order of magnitude larger.
Either you're making numbers up or we live in different realities
Hardware acceleration has existed for years...Maybe stop making assumptions and check out what terminals can do. They've come a long way since the 80's. I'd suggest starting with something like ghostty.
[0] https://notcurses.com/
I'm also not sure why you think it's an extra layer between the gpu. Both the browser and terminal emulator are sitting in top of the OS. But also remember if you run headless then your OS doesn't need to load the desktop environment, though you can still use the CLI. At this point clearly the GPU is seeing less, right?
My logic with it being an additional layer is that instead of the browser rendering text to the screen, it would have to speak with the terminal for the terminal to instead render text to the screen. Same goes for rendering graphics. Besides a headless system I don't see much of a benefit to it.
Edit: A comment here linked to https://www.brow.sh/ It looks amazing.
If you're willing to live in elisp, Emacs is amazing. I'm not, I'm always going to want to do it with ruby, and well, Emacs doesn't let you do that.
https://notcurses.com/
It's glorious
[0] https://www.brow.sh/
https://sr.ht/~ireas/cursive-markup-rs/
the whole cursive library strikes me as very html-like in layout
Rust is simply not meant for GUI-based data design but I still want Qt in Rust. That's it. Not QML or Slint. No markup at all. None of the immediate mode things. No other languages. Definitely not GTK. I'm worried it will never happen for Rust and it will be such a missed opportunity.
This topic comes up often, so I wrote a blog post explaining why I think a DSL is a good fit: https://slint.dev/blog/domain-specific-language-vs-imperativ...
Why Rust? Because I like its power and with recent developments such as subsecond the compile times are absolutely negligible.
Whereas when kovid made the kitty terminal protocol, it got implemented by the next 3 or so new terminal emulators. You don't get this kind of modernization from any other UI solution save browsers. And no way do I want to do web development for my own stuff. I suppose I could target Dillo or something like Servo, but I'd be more inclined to consume the base X11 protocol, as Vidar H did.
My Ruby terminal protocol implementation has smooth abstractions from methods performing the bare VT control calls up to semantic methods with better naming, to flexible and extensible text field abstractions. All the concerns are separated nicely and Ruby lets me scope everything just right, so I can call a debugger anywhere as the necessary logic is scoped module-wide.
I simply cannot imagine having any kind of fun doing this in a static compiled language. And I'll be able to build on top of this to make things that aren't editors.
Which is great, Zed's stack is pretty damn good. But like anything not yet widely used outside of its original use case, it can be rough around the edges, and just plain doesn't support anything that is not needed by Zed.
I'm betting on Slint. I kind of hated QML but it looks like they have learned a lot of lessons.
I really want to love gpui and would like to avoid using webviews, the advantage of web-based apps is that accessibility is (relatively) easy to do if you’re attentive to it. At the time I looked at it, gpui did not support screen readers etc at all.
I suppose I understand why they made that decision given their business priorities, but it’s hard for me to tell my vision-impaired friends and colleagues that there’s literally no way for them to use my app.
I love how Slint works on embedded devices too.
Egui is easy to get started with, and has a lot of widgets that work out of the box. The performance story isn't great, layout options is terrible (largely due to being immediate mode), and it is not very customizable. You take what they give you, and you like it.
Iced is a phenomenal and well-thought out API that is a wonder to work with. When it does what you need, which it often doesn't because it's not nearly as complete as the alternatives. But if you know that a monad is a monoid in the category of endofunctors, Iced might be right for you.
Slint is like Qt, but Rust. I don't think I need to say any more - if you have used Qt before, that sentence either immediately sold you on it, or convinced you to never go near it.
GPUI is a wonderful, extremely fast, stable, perfect API. If you are making a cross-platform native text editor. If you are doing anything else, sorry :(
There are a slew of projects bridging rust to run packaged browser apps which have some sort of DSL for specifying HTML front ends. People seem to like this for some reason. Some people also like being chained up in leather and whipped. I sometimes wonder if these are the same people.
Ratatui really is the best of the bunch. It has layout, accessibility, nice and easy user interface. It's a wonder to work with. Only problem: it is a TUI, not a GUI.
> Inspired by the gaming world, we realized that the only way to achieve the performance we needed was to build our own UI framework: GPUI. [0]
GPUI is not widely used because they only recently started publishing in crates.io [1] and still AFAIK their documentation is not that great yet, I suppose people will start using soon enough it, I was thinking on using it over Iced that was the other GUI that I feel that have future (because it's used by Cosmic Desktop).
[0] https://zed.dev/blog/videogame [1] https://crates.io/crates/gpui/versions
https://github.com/zed-industries/zed/tree/main/crates/gpui
See the discussion on a collection of elements ontop
https://news.ycombinator.com/item?id=45719004
I think writing a useful GUI has considerable overhead no matter which technology you use. In addition they cause other difficulties, like testability, i18n, l10n and accessability.
This is why people often resort to command line tools, rightfully so. There are cases, however, where a CLI won't cut it and I believe TUI's are a nice and lean solution that sits right between CLI and full-blown GUI and isn't going anywhere.
Most TUIs don’t have these either. So I don’t see this as a difference between TUI/GUI. If you want to make a GUI and want to ignore these things, you are free to do so.
An old school DOS TUI reads keyboard input one character at a time from a buffer, doesn't clear the buffer in between screens, and is ideally laid out such that a good part of the input is guaranteed to be fixed for a given operation. They also were built without mouse usage.
So an operator can hammer out a sequence like "ArrowDown, ArrowDown, ENTER, Y, ENTER, John Smith, ENTER" and even if the system is too slow to keep up with the input, it still works perfectly.
Modern GUIs almost never make this work near as well. You need to reach for the mouse, input during delays gets lost, the UI may not be perfectly predictable, sometimes the UI may even shift around while things are loading. Then also neither does Linux, I find that the user experience on DOS was far better than with ncurses apps that have all kinds of weirdness.
There's no standard to communicate TUI semantics to assistive technology, and whatever few standards actually exist (like using the cursor to navigate menus instead of some custom highlight) aren't followed.
With GUIs, those standards exist, and are at least somewhat implemented by all major (non-Rust)UI frameworks.
C| Column Wide |
o| |
l||
1|2|
> This is absolutely not true for a GUI which could easily just be an opaque rendered canvas. Are you not aware of OCR? Besides, GUIs have special accessibility tools, which almost none of the TUIs have, so your opaque canvas isn't universal.
> The fact remains:
That's a myth, not a fact, and you fail to establish "the fact" even in the most basic example
What’s actually hard with screen readers isn’t getting text (that’s been easy on most GUI systems for decades) but communicating things in the right order, removing the need to see spatial relationships or color to understand what’s going on.
TUIs make that harder for everything beyond mid-20th century-style prompt / response interfaces because you don’t want to have to reread the entire screen every time a character changes (and some changes like a clock updating might need to be ignored) so you want to present updates in a logical order and also need to come up with text alternatives to ASCII art. For example, if I made a tool which shows server response times graphically a screen reader user might not want to hear an update every second and if the most interesting thing was something like a histogram I might need to think about how to communicate the distribution which is better than rereading a chart every second only to say that the previous one has shifted to the left by one unit and a single new data point has been added.
Those are non-trivial problems in any case but they’re all harder with a TUI because you’re starting with less convention and without the libraries which GUI interface developers have to communicate lots of context to a screen reader.
There's no protocol that tells a screen reader to say something different than is actually displayed on the screen. The best you can do is having a whitelist of screen reader process names and changing how your TUI works if one of them is detected, but that's brittle and doesn't work over SSH. You'd also have to think about how to do container escaping and interfacing with the host system when you're running in WSL, as the screen reader is almost certainly on the host side.
I find egui far easier than Ratatui.
In the linked article the author had trouble building Qt for windows and because they wanted to go through 40+ GUI libraries they skipped it instead of pushing through. That's why it doesn't show up in final short-list of good options.
In my books (writing Rust since 2013, but haven't done any GUI work in it), Qt and Slint are the best options out there.
Every GUI I replace with a TUI is one less flow-breaking obstacle where I have to suddenly reach for the mouse.
Haha!
It made the post more amusing, actually. I sighed when I saw "Windows Narrator" suddenly.
https://terma.mattmay.dev/
71 more comments available on Hacker News