No, the people making TUIs in Rust are making TUIs because they love TUIs, and because Ratatui is pretty delightful. The state of GUI frameworks in Rust is irrelevant for this purpose, because even if there existed your ideal of Qt in Rust (putting aside the debatable notion that Qt is some sort of pinnacle of design), the people making TUIs wouldn't care, because that's not what they want to make.

It's amusing reading things like this. Meanwhile, we have at least 4 high-quality, practical GUI frameworks to choose from. You want QT in rust? I get that, but that is different from your claim about the state of GUIs in rust.

"I like the A tool in category B. System C doesn't have tool A; system C is dreadful in category B".

I think you could have made the acute part of this argument about GUIs in rust 3 years ago, but not today!

I need to try Slint and GPGUI. I love EGUI, but need to do a proper comparison; could be missing out. This seems to be a concern of a different nature from the one you describe!

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.

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.

Why does that link redirect to a fart sound hosted on Wikipedia?

"GUI situation in Rust is dreadful"

I have to agree with this, but for a lot of different things other than GUI as well. My friends all want me to use Rust, but I moved back to C++ after trying to do a lot of different projects in it after finding every crate I needed to be a WIP or abandoned state. There are the massive crates that are super popular of course, but it seems that once you get off the popular beaten path the available crates becomes far worse than any other language I have ever used.

Of course comparing Rust to something like Python or C++ is unfair to Rust, since Rust has had less time to develop those packages, but I think its more about the community at this point. I just don't see any enthusiasm for working on crates/frameworks. Most of the time when I find a crate I need, its sitting at version 0.3.0, last updated 1-3 years ago, with the documentation simply stating "Reimplementation of X in Rust, go read X's C++ documentation on how to use."

Given Qt consists of hardcore lovers of old C++, this is unlikely to happen in this generation.

What about Iced or libcosmic (based on Iced)?

Doesn't https://github.com/longbridge/gpui-component tick all your boxes ?

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...

The linked post is worthless. It’s a bunch of whining about how various rust stuff doesn’t work correctly on Windows “The most popular OS for developers.” Nobody cares.

I think it's pretty normal to have a language dedicated to the UI structure. It should be declarative for easy machine manipulation with a WYSIWYG editor and could be translated to code before compilation.

My reference in this are Delphi .dfm files, which you rarely have to edit manually because they're handled by the IDE form builder. It is still a fantastic IDE to build native UI apps and I don't see a reason why Rust couldn't be used the same way.

"Maybe one day an AI bro who pays for Twitter will contribute something positive to society, but this is not that day."

Haha!

there is this new library: https://longbridge.github.io/gpui-component/

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.

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?

Browsh [0] - it runs firefox headless, and renders everything to ascii in the terminal

It's glorious

[0] https://www.brow.sh/

I use this one pretty often. It’s great. https://chawan.net/

> 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

Not rust, but check out nimwave: https://github.com/ansiwave/nimwave

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

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.

> 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.

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...

> 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.

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.

> 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.

In addition to other comments, it's the only real way to make a usable GUI-like experience over SSH.

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.

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.

TUIs have the constraint that they don't have a mouse (or is optional at best).

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.

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.

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

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.

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.

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.

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.

IMO it's like seeing kids bust out disposable kodak cameras at the bar: generational nostalgia

Hmm, that sounds bad. Were you running the debug build? Like just running 'cargo run'?

> P2P terminal game about spacepirates playing basketball across the galaxy

Absolutely fantastic description right there.

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".

Aren’t all of these in a sense personal projects? If it works for the developer, that’s enough.

I use gitui on Windows and it is amazing, though mostly from a git bash shell.

I think they're saying this crate is why Rust is experiencing a TUI revolution.

Charm would probably say the same for Go.

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

CA Clipper database stuff was my jam! I only wish I had gotten into Turbo Vision. I used to watch my users fly through db apps filling out forms, hititng TAB between fields. There was just something so natural about it. The first app we ported to a web-based solution was really painful to watch.

Most popular? https://justuse.org/curl/

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

Kulala nvim plugin or emacs rest client

xh has sessions. https://github.com/ducaale/xh

https://posting.sh/

fzf is Go. There is Skim, which is done in Rust.

Rust has a culture of using lots of dependencies in general. I'm not super happy about this. I'd prefer a few larger dependencies, but most of the time I don't have the time/energy/talent to rebuild (or even vendor) these dependency trees

That's pretty much how I would expect a UI framework to work. As long as each widget class only depends on the UI base classes the dependencies should be small and grow proportionally to the number of widgets types used by the app. This should also being much less version churn than a big central library including everything.