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.
Every GUI I replace with a TUI is one less flow-breaking obstacle where I have to suddenly reach for the mouse.
I am building tooling around "Verifiable Credentials" (the W3C standard, OpenID standard, and all the standards around and below it).
So me and my co-workers need tools to check JWTs, resolve DIDs, generate Proof of Possession, .well-known contents and services discovery, do OpenId Connect flows, interpret "offer requests", "presentation requests", QR-codes, etc. It started as a bucket of random commandline things that random devs whipped up when needed (in typescript, python, bash, rust, some PHP), and now slowly consolidated into a consistent "toolkit". I am currently still porting most of these tools to Rust and make their CLI interface and IO consistent.
But from there I'll be adding a TUI very quickly.
By no means meant as "end-user" software - those exist and called "wallets". But for developers and devops working in this niche. These don't need a GUI. I'd even wager these users don't want a GUI but prefer a TUI, but in any case, the TUI is just so much easier and more accessible for me as a dev that it's the choice between a TUI+CLI or no UI, just CLI.
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.
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.
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.
I find egui far easier than Ratatui.
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."
GUI is kind of unique because it's a really hard problem - both a ton of work and also a bit awkward to make ergonomic in Rust.
> last updated 1-3 years ago
That's way too low a bar. I bet most of these niche C libraries that don't have Rust equivalents are similarly slow-moving.
GNU Make regularly goes 4 years without a release but it's still alive.
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.
https://github.com/zed-industries/zed/tree/main/crates/gpui
See the discussion on a collection of elements ontop
// Vidrun, born of the sea-wind through the spruce
// Vidrun, green-tinged offshoot of my bough, joy and burden of my life
// Vidrun, fierce and clever, may our clan’s wisdom be yours:
//
// Never read Hacker News
// - Aphyr, "Hexing the technical interview"
if (document.referrer.startsWith("https://news.ycombinator.com")) {
document.location = "https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fart.wav"
}
"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!
It's no less or more equipped than C or C++, so not really sure what to make of this comment given the username lol.
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.
It made the post more amusing, actually. I sighed when I saw "Windows Narrator" suddenly.
Because it is quite easy to do.
There are also TUIs in other languages, just Rust is more cool.
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...
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.
Why Rust? Because I like its power and with recent developments such as subsecond the compile times are absolutely negligible.
Haha!
[1]: https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fa...
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.
Edit: A comment here linked to https://www.brow.sh/ It looks amazing.
> but why would you render to a low-resolution 2D buffer with random character-hacks
> huge amount of overhead
Either you're making numbers up or we live in different realities
> actual hardware acceleration?
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.
It's glorious
You can already do this, since the 90s: Lynx[1] and w3m[2] have both existed for more than three decades at this point.
I mentioned those by name...
>> I know there's some browsers but things like W3M, Lynx, or *links* are... rough...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://sr.ht/~ireas/cursive-markup-rs/
the whole cursive library strikes me as very html-like in layout
https://github.com/benjajaja/mdfried/
Markdown is really cool in the sense that you can still look at the raw text and read it easily. But one thing that always made me load up .md files in the browser was that it's just much easier to read when the headers are bigger.
So I wrote a markdown viewer that renders the headers as images. You need to configure your font once for it to work, can't really detect the terminal font. It obviously also renders inline images, which was another reason to use the browser.
And then, Kitty developed the novelty https://sw.kovidgoyal.net/kitty/text-sizing-protocol (I think it's now also implemented in Ghostty), which means we can skip the text-to-image processing and directly leverage that protocol.
The good thing is that the image renderer definitely works on ghostty!
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
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.
[0] https://github.com/NimbleMarkets/ntcharts/blob/main/examples...
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.
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 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.
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.
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.
ssh teletekst.nl
[1] https://tweakers.net/geek/237754/nos-maakt-teletekst-beschik...
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.
I see that there are some related discussions on the github: https://github.com/ratatui/ratatui/discussions/1927. Not sure if there is a solution though.
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.
BTW, the video at the top of the repo readme won't open on any device I own.
Absolutely fantastic description right there.
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.
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
Submitters, please remember this from the guidelines:
... please use the original title, unless it is misleading or linkbait; don't editorialize.
Bluetui – A TUI for managing Bluetooth on Linux
https://news.ycombinator.com/item?id=45817114 https://github.com/pythops/bluetui
There’s a very real chance I just missed some initialization code that Ratatui might do out of the box that the other library was not.
Edit: Issues experienced by windows users were no colors, terminal flashing on every keypress, all keypresses registered as double.
Edit2: This miniature rant inspired me to go back to the commit and submit a patch to eliminate the event reporting on KeyUp and enable terminal colors.
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".
Not in the real world, where most of the useful software is not in fact written in Rust, nor Go for that matter.
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,..).
Need to dust off my Turbo Vision and Clipper projects.
I find these apps so increadibly useful, I almost want to learn Rust :D
Any recommendations for something that’s ergonomic to use and looks nice?
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
