How is the Windows support in Ratatui? I recently developed something with a different library only to discover it did not work very well for my windows users and ended up having to build a GUI with Iced.
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.
Apart from what you said about the GUI situation in Rust (which I disagree with) I think TUI's have their niche.
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.
You basically preempted nearly every single option, including an incumbent one. I don't believe it's fair to judge Rust based on its compatibility with Qt alone - something written in C++. Nothing against C++, but it's harder to get C++ and Rust to work together. You haven't addressed Iced yet, though going by your requirements, you're unlikely to be satisfied by it as well. Iced is not there yet, but it is the native GUI toolkit of the Cosmic desktop.
Author of one of these "markup"-based toolkits here. I believe that Rust might not be the best language syntax to express UI. I am curious why you are so strongly against using a DSL.
I kept forgetting Narrator is a Windows program, and the post read like the author was referring to the "Narrator voice in their head" while testing the UIs.
It made the post more amusing, actually. I sighed when I saw "Windows Narrator" suddenly.
I want a small wrapper around slumber so it can take the same command line arguments and options as curl. I now there are several attempts at making a graphical UI for curl, but slumber has a very nice and simple cli.
I'm really waiting for the TUI web browser. That would let me live completely in the terminal.
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.
But.. why? Like I do get the occasional need where it's easier to just see an html page in the terminal, but why would you render to a low-resolution 2D buffer with random character-hacks with a huge amount of overhead, over having a real buffer and just writing pixels to it, with actual hardware acceleration?
Something like ELinks could be created by writing a simple TUI on top of the Servo engine. Then it would be able to handle even complex Web pages full of JavaScript which is a huge chunk of the modern Internet.
Why would you want to live in a terminal? That's extremely limiting. What you really want is Emacs. Emacs has both a TUI web browser (EWW) and info browser already. You can even run vim in Emacs if you want, either the "real" (and inferior) thing via vterm, or use evil mode or another modal mode for Emacs like god mode.
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.
Godot is neat for personal tool-making where I just need a small gui with basic controls and can express the whole proggie in just GdScript (API has sufficient OS interactions for most needs), I just whip it out for those when I otherwise don't really use it anymore, just keeping it around for that. Stuff like that: https://postimg.cc/VJc0pWbB
I love Godot and think it has a great deal of potential for this kind of thing. Sure using a game loop isn't really very efficient for basic UI application, but in your case that doesnt really matter too much. That being said, I really don't like how it handles UI themeing.
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
TUI libraries have sufficiently abstracted away the low-level quirks of terminal rendering that the terminal has become something like a canvas[0] available in the IDE with no extensions. This is quite a nice DevX if you want to display the state of an app that does something to data, without writing the necessary plumbing to pipe that data to a browser and render it.
The low-level terminal stuff is still grody as hell. Years ago, HN had some blogposts from someone who was rethinking the whole stack, but I dunno what happened to that project. If people really like TUIs, eventually they're going to stop doing the 1980s throback stuff.
It's still around. Still doing its thing. One developer drafted a backend to ratatui for it, but he's been silent lately. I'm only marginally interested in that angle as its endgame "just" lands in TurboVision but Rust! and having to stay compatible with the feature-set of terminal emulation defeats the point.
They did this in the 1970s and 1980s too, then they were called “forms libraries” but were often full application frameworks in ways that would be familiar to modern developers of native graphical apps.
I think that a lot of people here at HN have had bad web interfaces and GUIs inflicted on them for a long time, that a TUI is a welcome change and a big improvement. TUIs are limited, which make it hard to create great interfaces; but those limits also make it hard to create really bad interfaces. Also the TUI is genuinely good at simple-to-moderate complexity software. For an example, try out Midnight Commander.
> I've seen lots of TUIs lately, why is that? What is the renewed interest?
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.
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.
Idk, I see it them all the time on the rust subreddit. Like, cool, but my friend, I have like ten brain cells and all of them are in overdrive. I’m not going to remember I have your TUI app installed AND remember the commands to make it work. If I have to use a CLI I just save the command I need in a text file so I don’t have to look them up. Just give me ang button any where. I’m not picky.
oh man, I haven't thought about xpra in a while! Xpra was a layer of indirection between X clients and X server so you could ssh in, run eg firefox, disconnect, and then reconnect and pick up Firefox where you left it.
The main reason for me is simple keyboard navigation. I don't want to click through links and menus, I don't want to use the mouse at all. I think that's also why tiling window managers are popular again.
My theory, web apps are extremely bloated and slow, teams behind it always “optimize” and switch things up, and desktop apps are usually just wrapped web apps. TUI developers don’t mind settling and not always messing up the product and they keep the TUI “lean and mean”. Some users appreciate fast, simple UIs and they don’t want to be constantly A/B tested on only for the core experience to break all the time.
i think this might be caused by codex.
it's open source, many people use it and it uses ratatui. People check how it is implemented and discover ratatui.
I believe this might be current most popular application using this library.
Yeah I think it’s the software equivalent of “go back to the land” type movements. Resurgence of Linux tiling window managers, NeoVim, TUIs. Everything in web and Electron land feels busy, attention grabbing, and bloated. Heck, even VSCode’s defaults are a kind of cluttered.
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.
That's a big question. I think TUIs are great for glue processes, and it doesn't hurt when they look pretty. They're also excellent first projects with composable interfaces. Shell code is such a pain. It's quick and dirty, but there are a lot of footguns. The main challenge is reducing the friction of making a TUI to the point where it's easy to execute an idea, and a lot of frameworks do this really well. Add the proliferation of LLMs on top, and maybe that could explain it?
The terminal remains an extremely compelling computing environment in spite of its limitations and fifty years of technical debt. As anachronistic as arcane escape codes and box drawing characters seem in $CURRENT_YEAR, the fact remains that nothing has arisen to fill its niche.
They're easier to program and seamlessly integrate into the terminal. That's basically it, other than that they're worse than normal GUIs. Also, GUI frameworks aren't that mature in Rust in particular.
Unrelated to the article, a lot of my millennials could see web and then mobile coming, focused on web & mobile, and as a result just weren't really participating in C and C++ development. We used terminal applications leftover from peak GNU.
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.
TUIs being designed by engineers for engineers make them rather timeless. Extra points for being keyboard-first: lots of modern GUI tools don’t even consider the keyboard for anything other than text input, to the point that even tab order is broken, if it works at all, or the escape key closes multiple stacked modal windows, or enter doesn’t submit the dialog, or…
I don't care much about forms and windows in the command line (I've had enough of turbo vision back in the 90s), but I don't think I am alone in wanting to see some progress bars and stats for long running processes. So 2% of these libraries is actually pretty useful.
I’ve been experimenting with a coding agent project [0], and ratatui-rs became my framework of choice for building its first TUI. [1] The framework now ships with native list view support and improved terminal capabilities, including smoother mouse interaction and text selection.
I tried Ratatui for a small app. I just needed a textbox, and I copied an example from the tutorial. When typing (quickly), the CPU usage was crazy. I was expecting something like 0% CPU (it's just typing text, a similar app in Go uses nothing) but it was using like 8% CPU.
I would guess I was doing something wrong, but it was really running an example from the official website. So I gave up on Ratatui.
Some of the most interesting projects here have the worst installation stories.It's sort of tilting at windmills to not acknowledge that people are going to mostly install through package managers for their platform by advertising it as such. I'm not suggesting there's anything wrong with building from source. On the contrary, I think it's fantastic as many targets are supported here as there are! I think it's a shame more people aren't discovering them is all.
Rust, following Go's footsteps, has made it very easy to distribute-and-compile from source. They've taken all the pain out of the compiling-from-source pipeline, through "go build" or "cargo build"
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".
The reason I was put off by Rust was compiling from source. I experimented with a ports collection package management system similar to those used in BSD a while ago, and every time a Rust program needed to be compiled, I could go to sleep; no, basically rendering the system unusable. It was like the dependency abyss of NPM combined with the worst possible compile times, even worse than C++.
The reason for the rate of updates is isially for one reason: Trust and Stability. Instead of trusting a myriad people all over the world to do their job well, I trust one team to ensure that all the tools I need do run well.
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,..).
Okay, but where do you put it? I mean, yes, I know there's /usr/local/bin and /opt/bin, but why do I have to compile then mv it myself? It's a small paper cut. Does cargo or go have a global build command? That would be a nice all-in-one. And why should I have to download the source code if, honestly, I don't care as long as it works? Nah, I don't think build from source has taken over at all. It's 2025 and I use a package manager (or three) on every major operating system across multiple languages. It's because, as a vendor experience, I can one-line and use just about anything.
the title of this post is odd? it’s a showcase of TUI applications built with this Rust crate — which I am hearing about for the first time, and am interested in. I was expecting a blog post on why Rust is experiencing a TUI revolution or something
Charm was my introduction into the world of ssh apps which prompted me to create https://pico.sh
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 terminal app is running during an interactive shell session. A ssh app basically allows you to SSH into the app, without ever ending up in the shell.
Would be more and more useful to have terminal CLI utilities like running a given prompt or agent over a folder. I'd use that for auditing legal compliance for some projects.
Wow, I did not know that some of my most loved apps in terminal are written in Rust: yazi, atuin, bottom, isn't fzf also written in Rust? And today I learned about some more I want to explore: csvlens, bandwhich, dua, material, oha.
I find these apps so increadibly useful, I almost want to learn Rust :D
What is the best / most popular / user friendly terminal http client I can replace postman with. Has a history I can search, save favorites, secure etc.
I like smaller more focused tools on the terminal. You can make these all work together pretty reasonably with a little glue. Hurl, mitmproxy, httpie with http-prompt. I tend to prefer mitmproxy sessions and massaging that with Python/curl as needed for repeating and tweaking. User friendly is relative, but these tools work well. Python for tweaking http streams in mitmproxy is powerful and rather friendly for what you get in return. Mitmproxy lets you easily save flows with a bit of Puthon glue to output httpie commands giving history, and you can save mitmproxy sessions.
Ratatui is neat but the way it's architected, you need to take on third party dependencies for each individual widget. And we're talking basic things like spinners, checkboxes, text areas, etc. -- there aren't too many widgets built into ratatui itself. I didn't like the idea of taking all that on so instead I went with something more handrolled.
How is the Windows support in Ratatui? I recently developed something with a different library only to discover it did not work very well for my windows users and ended up having to build a GUI with Iced.
People keep asking why TUIs in Rust and the answer is because the GUI situation in Rust is dreadful: https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...
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.
Apart from what you said about the GUI situation in Rust (which I disagree with) I think TUI's have their niche.
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.
Zed (https://zed.dev) is a GUI built in rust. Im not an expert in GUI building so maybe I'm wrong and they used a separate language for the GUI.
They use rust for the gpu
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
You basically preempted nearly every single option, including an incumbent one. I don't believe it's fair to judge Rust based on its compatibility with Qt alone - something written in C++. Nothing against C++, but it's harder to get C++ and Rust to work together. You haven't addressed Iced yet, though going by your requirements, you're unlikely to be satisfied by it as well. Iced is not there yet, but it is the native GUI toolkit of the Cosmic desktop.
Author of one of these "markup"-based toolkits here. I believe that Rust might not be the best language syntax to express UI. I am curious why you are so strongly against using a DSL.
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...
I'd like to have non-imperative gui code in Rust.
Why Rust? Because I like its power and with recent developments such as subsecond the compile times are absolutely negligible.
Why does that link redirect to a fart sound hosted on Wikipedia?
A quick glance at the website in question suggests that its owner may not be particularly mentally mature.
The author doesn't like HN.
The Referer header strikes again. You'd think the typo in its name would be the worst thing about it, but nope.
Doesn't https://github.com/longbridge/gpui-component tick all your boxes ?
I kept forgetting Narrator is a Windows program, and the post read like the author was referring to the "Narrator voice in their head" while testing the UIs.
It made the post more amusing, actually. I sighed when I saw "Windows Narrator" suddenly.
I want a small wrapper around slumber so it can take the same command line arguments and options as curl. I now there are several attempts at making a graphical UI for curl, but slumber has a very nice and simple cli.
I'm really waiting for the TUI web browser. That would let me live completely in the terminal.
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.
But.. why? Like I do get the occasional need where it's easier to just see an html page in the terminal, but why would you render to a low-resolution 2D buffer with random character-hacks with a huge amount of overhead, over having a real buffer and just writing pixels to it, with actual hardware acceleration?
SSH access over a slow network connection?
[dead]
Browsh [0] - it runs firefox headless, and renders everything to ascii in the terminal
It's glorious
[0] https://www.brow.sh/
Not rust, but check out nimwave: https://github.com/ansiwave/nimwave
I use this one pretty often. It’s great. https://chawan.net/
This actually looks pretty reasonable. Thanks! I'll definitely be giving it a try
> I'm really waiting for the TUI web browser. That would let me live completely in the terminal.
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
ELinks is the TUI browser I've used since .... forever.
https://github.com/rkd77/elinks
Something like ELinks could be created by writing a simple TUI on top of the Servo engine. Then it would be able to handle even complex Web pages full of JavaScript which is a huge chunk of the modern Internet.
Why would you want to live in a terminal? That's extremely limiting. What you really want is Emacs. Emacs has both a TUI web browser (EWW) and info browser already. You can even run vim in Emacs if you want, either the "real" (and inferior) thing via vterm, or use evil mode or another modal mode for Emacs like god mode.
the cursive tui library does some html rendering
https://sr.ht/~ireas/cursive-markup-rs/
the whole cursive library strikes me as very html-like in layout
(shameless plug) I don't know if anyone would be interested in taking this but I have what I think is a really nice project. Integrating this;
https://github.com/ironcalc/TironCalc
Into the main repo :
https://github.com/ironcalc/ironcalc
Now, I'm not 100% convinced ratatui is the way to go after seeing what the folks of Microsoft did with edit.
Anyhow, I think TironCalc is a great open source project to work with Rust and Ratatui.
I've seen lots of TUIs lately, why is that? What is the renewed interest?
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
> What is the renewed interest?
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.
Godot is neat for personal tool-making where I just need a small gui with basic controls and can express the whole proggie in just GdScript (API has sufficient OS interactions for most needs), I just whip it out for those when I otherwise don't really use it anymore, just keeping it around for that. Stuff like that: https://postimg.cc/VJc0pWbB
I love Godot and think it has a great deal of potential for this kind of thing. Sure using a game loop isn't really very efficient for basic UI application, but in your case that doesnt really matter too much. That being said, I really don't like how it handles UI themeing.
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
TUI libraries have sufficiently abstracted away the low-level quirks of terminal rendering that the terminal has become something like a canvas[0] available in the IDE with no extensions. This is quite a nice DevX if you want to display the state of an app that does something to data, without writing the necessary plumbing to pipe that data to a browser and render it.
[0] https://github.com/NimbleMarkets/ntcharts/blob/main/examples...
The low-level terminal stuff is still grody as hell. Years ago, HN had some blogposts from someone who was rethinking the whole stack, but I dunno what happened to that project. If people really like TUIs, eventually they're going to stop doing the 1980s throback stuff.
This series? https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
It's still around. Still doing its thing. One developer drafted a backend to ratatui for it, but he's been silent lately. I'm only marginally interested in that angle as its endgame "just" lands in TurboVision but Rust! and having to stay compatible with the feature-set of terminal emulation defeats the point.
They did this in the 1970s and 1980s too, then they were called “forms libraries” but were often full application frameworks in ways that would be familiar to modern developers of native graphical apps.
I think that a lot of people here at HN have had bad web interfaces and GUIs inflicted on them for a long time, that a TUI is a welcome change and a big improvement. TUIs are limited, which make it hard to create great interfaces; but those limits also make it hard to create really bad interfaces. Also the TUI is genuinely good at simple-to-moderate complexity software. For an example, try out Midnight Commander.
> I've seen lots of TUIs lately, why is that? What is the renewed interest?
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.
> What is the renewed interest?
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.
Idk, I see it them all the time on the rust subreddit. Like, cool, but my friend, I have like ten brain cells and all of them are in overdrive. I’m not going to remember I have your TUI app installed AND remember the commands to make it work. If I have to use a CLI I just save the command I need in a text file so I don’t have to look them up. Just give me ang button any where. I’m not picky.
In addition to other comments, it's the only real way to make a usable GUI-like experience over SSH.
I've generally had good experiences with the various compressed X11-like tools. One example is x2go, but there are a few.
oh man, I haven't thought about xpra in a while! Xpra was a layer of indirection between X clients and X server so you could ssh in, run eg firefox, disconnect, and then reconnect and pick up Firefox where you left it.
You can also serve a window server over ssh
The main reason for me is simple keyboard navigation. I don't want to click through links and menus, I don't want to use the mouse at all. I think that's also why tiling window managers are popular again.
My theory, web apps are extremely bloated and slow, teams behind it always “optimize” and switch things up, and desktop apps are usually just wrapped web apps. TUI developers don’t mind settling and not always messing up the product and they keep the TUI “lean and mean”. Some users appreciate fast, simple UIs and they don’t want to be constantly A/B tested on only for the core experience to break all the time.
i think this might be caused by codex. it's open source, many people use it and it uses ratatui. People check how it is implemented and discover ratatui.
I believe this might be current most popular application using this library.
I'm surprised it isn't included in this showcase
Or Claude. There are more than a few developers on my team that prefer terminal interface for their codegen chatbots.
Yeah I think it’s the software equivalent of “go back to the land” type movements. Resurgence of Linux tiling window managers, NeoVim, TUIs. Everything in web and Electron land feels busy, attention grabbing, and bloated. Heck, even VSCode’s defaults are a kind of cluttered.
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.
That's a big question. I think TUIs are great for glue processes, and it doesn't hurt when they look pretty. They're also excellent first projects with composable interfaces. Shell code is such a pain. It's quick and dirty, but there are a lot of footguns. The main challenge is reducing the friction of making a TUI to the point where it's easy to execute an idea, and a lot of frameworks do this really well. Add the proliferation of LLMs on top, and maybe that could explain it?
High-level languages that compile to single binaries, and very good TUI frameworks (maybe inspired by Python Textual?) for them.
The terminal remains an extremely compelling computing environment in spite of its limitations and fifty years of technical debt. As anachronistic as arcane escape codes and box drawing characters seem in $CURRENT_YEAR, the fact remains that nothing has arisen to fill its niche.
They're easier to program and seamlessly integrate into the terminal. That's basically it, other than that they're worse than normal GUIs. Also, GUI frameworks aren't that mature in Rust in particular.
Unrelated to the article, a lot of my millennials could see web and then mobile coming, focused on web & mobile, and as a result just weren't really participating in C and C++ development. We used terminal applications leftover from peak GNU.
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.
IMO it's like seeing kids bust out disposable kodak cameras at the bar: generational nostalgia
TUIs being designed by engineers for engineers make them rather timeless. Extra points for being keyboard-first: lots of modern GUI tools don’t even consider the keyboard for anything other than text input, to the point that even tab order is broken, if it works at all, or the escape key closes multiple stacked modal windows, or enter doesn’t submit the dialog, or…
TUIs work better than GUIs. So much more powerful with so many less resources.
I don't care much about forms and windows in the command line (I've had enough of turbo vision back in the 90s), but I don't think I am alone in wanting to see some progress bars and stats for long running processes. So 2% of these libraries is actually pretty useful.
I’ve been experimenting with a coding agent project [0], and ratatui-rs became my framework of choice for building its first TUI. [1] The framework now ships with native list view support and improved terminal capabilities, including smoother mouse interaction and text selection.
[0] https://github.com/vinhnx/vtcode
[1] https://github.com/ratatui/awesome-ratatui
I tried Ratatui for a small app. I just needed a textbox, and I copied an example from the tutorial. When typing (quickly), the CPU usage was crazy. I was expecting something like 0% CPU (it's just typing text, a similar app in Go uses nothing) but it was using like 8% CPU.
I would guess I was doing something wrong, but it was really running an example from the official website. So I gave up on Ratatui.
Hmm, that sounds bad. Were you running the debug build? Like just running 'cargo run'?
Related from yesterday:
Bluetui – A TUI for managing Bluetooth on Linux
https://news.ycombinator.com/item?id=45817114 https://github.com/pythops/bluetui
Some of the most interesting projects here have the worst installation stories.It's sort of tilting at windmills to not acknowledge that people are going to mostly install through package managers for their platform by advertising it as such. I'm not suggesting there's anything wrong with building from source. On the contrary, I think it's fantastic as many targets are supported here as there are! I think it's a shame more people aren't discovering them is all.
Rust, following Go's footsteps, has made it very easy to distribute-and-compile from source. They've taken all the pain out of the compiling-from-source pipeline, through "go build" or "cargo build"
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".
The reason I was put off by Rust was compiling from source. I experimented with a ports collection package management system similar to those used in BSD a while ago, and every time a Rust program needed to be compiled, I could go to sleep; no, basically rendering the system unusable. It was like the dependency abyss of NPM combined with the worst possible compile times, even worse than C++.
The reason for the rate of updates is isially for one reason: Trust and Stability. Instead of trusting a myriad people all over the world to do their job well, I trust one team to ensure that all the tools I need do run well.
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,..).
Okay, but where do you put it? I mean, yes, I know there's /usr/local/bin and /opt/bin, but why do I have to compile then mv it myself? It's a small paper cut. Does cargo or go have a global build command? That would be a nice all-in-one. And why should I have to download the source code if, honestly, I don't care as long as it works? Nah, I don't think build from source has taken over at all. It's 2025 and I use a package manager (or three) on every major operating system across multiple languages. It's because, as a vendor experience, I can one-line and use just about anything.
If you have the Rust toolchain installed, installing is as simple as e.g.:
which will result in ripgrep being downloaded, compiled, and copied to a per user directory that's included on PATH as part of the toolchain.EDIT: Which is what I'm doing right now for a few of these that caught my eye.
> In effect, build-from-source has taken over "just use the distribution package".
Not in the real world, where most of the useful software is not in fact written in Rust, nor Go for that matter.
Shameless plug of my TUI game, also built with Ratatui
https://github.com/ricott1/rebels-in-the-sky
> P2P terminal game about spacepirates playing basketball across the galaxy
Absolutely fantastic description right there.
the title of this post is odd? it’s a showcase of TUI applications built with this Rust crate — which I am hearing about for the first time, and am interested in. I was expecting a blog post on why Rust is experiencing a TUI revolution or something
I think they're saying this crate is why Rust is experiencing a TUI revolution.
Charm would probably say the same for Go.
Charm was my introduction into the world of ssh apps which prompted me to create https://pico.sh
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
What’s an SSH app vs a terminal app?
A terminal app is running during an interactive shell session. A ssh app basically allows you to SSH into the app, without ever ending up in the shell.
A fun example of this is https://www.terminal.shop/
Any terminal app can be an “ssh app”. There isn’t really a distinction.
We've updated the title.
Submitters, please remember this from the guidelines:
... please use the original title, unless it is misleading or linkbait; don't editorialize.
ratatui has been around for quite a bit. it's what I'll reach out for if I need semi-complex TUIs in Rust fwiw
I am also now curious about alternatives/what differentiates this crate
Would be more and more useful to have terminal CLI utilities like running a given prompt or agent over a folder. I'd use that for auditing legal compliance for some projects.
Ratatui is awesome! Just built a little chat client with it, tons of fun.
https://terma.mattmay.dev/
So many MS-DOS application memories comming back, really don't get it in the age of cheap graphics.
Need to dust off my Turbo Vision and Clipper projects.
Nice. It would be also cool if they add 'cargo install %tool%' commands for each one.
Wow, I did not know that some of my most loved apps in terminal are written in Rust: yazi, atuin, bottom, isn't fzf also written in Rust? And today I learned about some more I want to explore: csvlens, bandwhich, dua, material, oha.
I find these apps so increadibly useful, I almost want to learn Rust :D
What is the best / most popular / user friendly terminal http client I can replace postman with. Has a history I can search, save favorites, secure etc.
I like smaller more focused tools on the terminal. You can make these all work together pretty reasonably with a little glue. Hurl, mitmproxy, httpie with http-prompt. I tend to prefer mitmproxy sessions and massaging that with Python/curl as needed for repeating and tweaking. User friendly is relative, but these tools work well. Python for tweaking http streams in mitmproxy is powerful and rather friendly for what you get in return. Mitmproxy lets you easily save flows with a bit of Puthon glue to output httpie commands giving history, and you can save mitmproxy sessions.
I also have this question!
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
xh has sessions. https://github.com/ducaale/xh
Kulala nvim plugin or emacs rest client
https://posting.sh/
Very dope. I really like dua as my mac only has 256 GB.
Ratatui is neat but the way it's architected, you need to take on third party dependencies for each individual widget. And we're talking basic things like spinners, checkboxes, text areas, etc. -- there aren't too many widgets built into ratatui itself. I didn't like the idea of taking all that on so instead I went with something more handrolled.
Oh good collection. This is good. Found lots of good tools here.
[flagged]
Why do you think there is not a sweetspot between cli and gui?
It's called emacs