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.
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.
1. Consistent font and sizing. Pick the font you find easiest to read and set it in the terminal, now all TUI apps use it at the correct size.
2. Consistent theming. TUI apps use the same color scheme as your terminal, as your vim, etc. A consistent "desktop" is less distracting. Especially when you don't have to deal with crappy Electron apps displaying animations and ads (looking at you Discord).
3. Efficient on screen real-estate. Most TUI apps don't waste a lot of space on "padding", "giving elements space to breathe" or other "correct UX patterns". They tile nicely.
4. Never and issues copy and pasting. I used a GUI chat app recently that wouldn't let me select text, seriously.
5. Did I mention they are fun to use and relatively easy to develop?
Yeah they all use the same palette, but they don't all use the palette the same way.
And copy / paste, "hm does this TUI intercept mouse clicks, ah it does, oh what was the key combo for my terminal emulator that allows to skip that? Crap I pressed ctrl-c instead of ctrl-shift-c". Or worse when you want to select text in a column-based TUI and your terminal emulator doesn't have any sort of column-selection handling.
Well-designed GUIs can be fully keyboard operated, where the mouse-driven interface only serves as a way to educate the user about which functionality is available. I'll use Tera Term (a serial terminal emulator) as an example. If you want to start a serial XMODEM transfer, you can figure out how to do it just by clicking around the user interface. You click on "File", then "Transfer", then "XMODEM", then "Send". Once you do it a few times, you remember the layout of the menus, and can start navigating solely by keyboard. Instead of "breaking your flow" by having to reach for the mouse, you just hold down Alt and type "FTXS". This is much faster, and you learned how to do it entirely from just using the program and observing which letters are underlined in the menus. There's no need to look at a manual or help page.
A well-designed TUI and GUI have great keyboard nav, discoverability, UX, and all. The question is more about what you want for the 99% of UIs that aren't well-designed nor polished, and what kind of worst-case you want to deal with.
By default, TUIs have bad discoverability unless the developer puts in the effort. But at least you have keyboard navigation and run in a terminal.
By default, GUIs have bad keybindings unless the developer puts in the effort. In the worst case they aren't even kb navigable. But at least they tend to be discoverable.
Going to shill for the Ultimate Hacking Keyboard here, specifically its mouse-keys capability, which is where I can move the mouse via WASD (or any other binding). I have both the touchpoint and trackball add-on modules, but I still use mouse keys to manipulate my cursor 99% of the time.
they do not, GUI is more capable of handling keyboards than TUI because terminals still have pretty dumb limitations where some modifiers aren't even visible/bindable!
This seems trivially false or disconnected from the important part of what I'm referring to here.
TUIs have to be navigable by keyboard. They could be garbage in every other way, but at least they have that.
GUIs might have keybindings as polish if the developers put in the effort. Otherwise they either don't have keybindings, or they rely on generalized keybindings that come with the OS/UI toolkit that can be bad/impossible in arbitrary ways, like if tab is swallowed by an input so you can't even tab past a component or dismiss a modal. Or the only GUI is inside a web browser.
This seems trivially false to you because you don't rise above the trivial, but also forget about similar trivial fails in TUIs.
> They could be garbage in every other way, but at least they have that
Not really, they could also not implement keyboard input for some interactions and only react to mouse. You could have a click-to-open-url in your terminal without a keyboard fallback setup. Of course, you could set it up, but that would be "polish if you put in the effort"
There is no limit to garbage.
> Also once your workflow is increasingly keyboard based (like when using a tiled window manager),
Exactly, for example, you've set your Windows key to be reponsible for all window-based movements, so you have it move/resize app windows and want to have the same key help you move/resize "inner windows/panes/columns" in a TUI app. Well, tough luck, the terminal doesn't even recognize this modifier!
Again, "as polish if you put in the effort" you can achieve anything via some external remapping to supported keys, but "otherwise" you don't have keybindings, and don't even have generalized fallback common (though not universal, again, there is no limit to garbage) to GUIs.
Or you'd be unable to bind some key combo because in a terminal that key combo is equivalent to regular typing and you need to timeout to differentiate between the two, so a permanent friction.
> tab is swallowed by an input so you can't even tab past a component
Of course you can, use your keyboard to move the mouse pointer and click outside of the input field. All pure organic keyboard-based interaction! "They could be garbage", but at lest you have that keyboard-based option (yes, only "polish/put in effort")
I've used some pretty bad ncurses apps that barely have keybindings, like oterm.
I'd probably put them in a third, discarded, mutant category where they are mouse-first applications that run in the terminal. Thus like GUIs, keyboard-support is bolted on.
So a better distinction here is mouse-first vs keyboard-first, but I think "TUI vs GUI" is close enough to that and it kinda stands in for that distinction in most cases.
Vim, tmux, and weechat would be examples of keyboard-first TUIs where mouse support is bolted on as polish, but never required.
Where you lose me is that every example you can think of where a bad TUI might not perfectly mesh into a keyboard-only workflow, the GUI counterparts to that example is much worse. So we would just agree that it's a bad TUI rather than anyone going "you're right, the average GUI is much better if keyboard-driven control is my priority".
I don't understand some of your examples though. Your super key is always at a global level that you wouldn't expect apps to read, that's the point. And using timeouts to handle keybinding collisions or something? Dunno what that looks like nor why you would do it. The examples are like if I said GUIs suck because it's a dreadful experience if you insist on using your mouse upside down.
> So a better distinction here is mouse-first vs keyboard-first, but I think "TUI vs GUI" is close enough to that and it kinda stands in for that distinction in most cases.
It's indeed a better distinction, but no, TUI vs GUI is nowhere close, specifically for your explicitly mentioned use case of "workflow is increasingly keyboard based" because that's exactly where GUI shines as it has much fewer fundamental limitations in keyboard handling.
> than anyone going "you're right, the average GUI
That's your strawman framing, why would I care about "the average"? It's not a limit for anyone, one can always choose a better-than-average app. My point is that at the top there is no comparison because TUIs offer nothing and have much bigger fundamental limitations.
So of course with the wrong framing you can find worse examples.
> And using timeouts to handle keybinding collisions or something? Dunno what that looks like nor why you would do it.
Terminals send Esc for Alt-X combos, so to differentiate those combos from a single Escape press you need to track timers (if no extra key signal, then it's Esc, if another key signal, then it's a combo). And Esc is one of the most used keys in e.g. Vim
> Your super key is always at a global level that you wouldn't expect apps to read, that's the point.
Of course I would! What I wouldn't expect is for the app to override any global OS function bound to that key, but I would definitely expect to be able to not waste a whole thumb-conveniently located modifier just because
That's very close to my point - you're used to some trivial keyboard workflow, so wasting the whole modifier is just fine, you can't even comprehend why someone wouldn't want that, it's like a mouse upside down!
IMO, the value in TUIs lie in 1) Composability: we've got really good tools for manipulating terminal windows like tmux, :term in vim, etc, whereas the same can't really be said for OS-level windows and 2) As a shibboleth: They implicitly state that they're built by and for keyboard-centric technical users, and thus the wants and needs of keyboard-centric technical users are going to be the valued over the wants and needs of the lowest common denominator. 3) They look cool.
1. if you use some external window manager tool, what workflow does tmux/term provide you that OS-level windows with that tool do not?
2. specifically for "keyboard-centric tech users" that's a big fail since the terminal platform is not capable of supporting advanced keybindings presisely because all they do is "target the lowest common denominator" (as defined in 1965) of keybinding support!!!
So your cool setup from a GUI code editor is simply not transferrable.
3. this is very rare, I mean, just look at the screenshots, a lot of them couldn't even add non-gapped borders=== ---!
1. I think the fact that you refer to "some external window manager tool", whereas you know the name tmux off the top of your head illustrates that first point.
2. Again, it's not about the possible capabilities. Objectively, GUI programs contain a superset of possible TUI programs (since your GUI program could be a terminal emulator). It's about it being a shibboleth: I can be pretty confident that the TUI application will have a keyboard-based workflow, and I can be pretty confident that the TUI application will be targeting a technical user base, because those are the only people building and using TUI tools. The "lowest common denominator" in that sentence was referring to the users not the systems.
1. I think the fact that you have nothing of substance and have to read into the fact that after reading your comment explicitly mentioning tmux I repeated that illustrates the point is invalid.
2. but what's the value of a shibboleth if it's not reflected in capabilities??? Why would you care that a TUI app targets "tech user base" if you also know it will be less capable in your 'keyboard-centric' workflow due to platform limitations? And LCD for users just doesn't make sense, what user quality are you min-aggregating?
Every text editor and most professional apps have elaborate hotkey schemes in practice, though. It's a matter of target audience and developer intent. There's nothing special about TUIs in regards to keyboard driveability, and they're heavily limited in just about every single way I can think of. Which is the main reason most TUI apps are simple and small utilities.
The very nature of being simple makes it so that the amount of hotkeys you have to learn is limited.
While most gui ones also have hotkeys, most people only remember a tiny selection and have to rely on navigating menus and dialogs to access stuff they can't remember which makes their usage very slow.
It depends on the goal, e.g. software like Maya is built for the world in which the amount of required work makes even average projects intractable if you're slow with your tools. Entire generations of actual masters of their craft have built their careers on being efficient with it.
Menus are also not slow by any measure, they're only needed for discoverability, can be navigated with the keyboard as well, and aren't that different from the menus many TUI apps have (e.g. Midnight Commander). Moreover, there are real novel ideas like Microsoft's ribbon, which basically combine vi-style input and discoverability. Hotkeys is just one way to drive a GUI app using the keyboard, out of many.
Anecdotal evidence here. My use-case needs some UI, but a full blown GUI is way, way overkill.
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.
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.
To be fair, TUIs are strictly worse accessibility-wise than GUIs.
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.
Text isn't more legible without structure, and without communicating structure, which is what various accessibility toolkits do, you don't get this supposed benefit
Text has inherent structure that GUIs don't. The ceiling for GUIs is higher (thanks to standards and supporting frameworks), but the floor for TUIs is higher.
Ok, what is the inherent structure of these two columns and how is a screen reader supposed to divine that structure without the framework telling it that there are 2 headers with the following text? And imagine the layout is space-separated as in cli utils
Even at the worst case, text can be read aloud and give some indication of what the screen contains. This is absolutely not true for a GUI which could easily just be an opaque rendered canvas. The fact remains: TUIs are inherently legible in ways that GUIs are not guaranteed to be.
Both false: you'll have NO indication if you read letters from different words out of order!
You'll not understand whether 'o' is a value or a continuation of the column name even in the primitive example above, and for anything even remotely complicated it's even worse.
> 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
There are ways to do it in most GUI applications. On Windows, pressing Alt will sometimes show you the combination to activate certain parts of the UI (keyboard accelerators). It's not obvious anymore because people don't focus on accessibility. Sadly, it's not common practice to ensure a good workflow, because it's assumed that they will use a mouse. Or people keep re-inventing TUI every time they think they want a terminal-friendly utility.
TUIs still need to comply with 508 so that “massive pain” is there either way.
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.
> In addition they cause other difficulties, like testability, i18n, l10n and accessability.
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.
Where I think TUIs had a niche GUIs don't quite reproduce is in the very particular way DOS TUIs processed input.
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.
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."
I strongly disagree with this. Obviously Rust hasn't had the decades of life that C/C++ has to give you weird niche libraries, but at this point the Rust crate ecosystem is huge and you have to go fairly niche before you find something where there simply isn't a Rust option. Usually you find something and it's a lot nicer than the C option.
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.
This is surprising to hear; my experience matches the parent comments' exactly. The crates exist, but are usually toys that haven't been applied to practical problem. This is a generalization, but it applies well in many domains. Often, they're someone's one-off school project, a "let's build X in rust" from someone who doesn't have a practical use case for X etc.
I'm going to agree with you here. I love rust, but this is a big down side. I have to do so much ecosystem building and low level stuff because the libs available don't exist, or are not in a suitably usable state.
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.
IMO, traditional GUI frameworks in Rust (like Qt) are difficult for the same reason that game engines in Rust are difficult: cyclical references. A window might contain a group box which contains a text field and a button. All of these are (direct or indirect) children of the window, but all children also hold a reference to their parent. Qt's signal-slot mechanism would also be difficult to implement in Rust.
They use Rust, but they basically reinvented the wheel for everything they did, because the existing GUI stuff in the rust ecosystem sucked so badly it wasn't worth fixing.
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 evaluated gpui for a project I’m working on. While I’ve found the rendering and performance to be great (and actually switched to Zed as my daily driver after playing with it), the (absence of an) accessibility story made me grudgingly just use tauri.
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 think they wanted more control over the GUI, so the best answer to that is build something that you have 100% control over. In one of their first blog posts they explain more in deep the reasons.
> 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).
I have used egui in actual projects. It is slow, opinionated in a bad way, not very customizable in terms of themes, and definitely not up to date in terms of latest GUI standards. It isn’t even the best RUST GUI project by any of those metrics.
Interesting! I am using it in some complex stuff with 3D graphics (A structural biology/molecular dynamics tool), and it is a great experience. I need to compare it to GPGUI and Slint; would love to compare the pros and cons first-hand.
As I said above, they all suck in some way. It's a matter of deciding what is most important to you and picking the one that sucks least for that.
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.
// 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"
}
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!
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.
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.
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.
Seriously, there is requirement to CPU draw UI components too ? OP didn't say that and it sounds crazy anyways. Even your point-of-sale terminal units with displays have integrated GPUs. Popular Ex in 2025: Qualcomm Snapdragon 810 SoC (octa-core ARM) with Adreno 430 GPU.
I mean if it requires a modern GPU, that leaves a ton of perfectly working older hardware out in the dust, even those with a GPU if they don't support modern APIs. That's a huge downside when the competing toolkits run just fine on the CPU.
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.
When I went to go look for a platform to implement a personal text editor on, I somewhat quickly settled on the vt100 terminal api with kitty extensions, particularly its keyboard protocol. Everything else locks you into, not only a language, everybody codes frameworks these days, nobody writes apis, but also what's essentially already a legacy solution, a framework is going to get updates at the speed of the developer's passion.
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.
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 just completely disagree. We have Slint, Dioxus, Tauri, Egui (best imo).
If Dioxus blitz renderer takes off them it will vastly better than 99% of options for other languages
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?
Character based interfaces are just nice, IMHO. The Borland IDE was the pinnacle of dev interfaces IMHO. It updated to have modern language server support etc would be my dream dev environment. It would be cool to see how far a compliant web browser could be taken in text mode. It's really sad that most terminals don't have proper image support, btw.
> but why would you render to a low-resolution 2D buffer with random character-hacks
Have you used a terminal in the last 5 years? We got graphics and everything now[0]
> huge amount of overhead
A... terminal... with... large overhead? Surely you're joking. Have you met any gui app? Microsoft word takes a few gigs. Have you seen electron apps like Spotify or slack? My fucking mail client takes over half a gig and neomutt takes almost nothing.
Either you're making numbers up or we live in different realities
> actual hardware acceleration?
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.
Wouldn't you still be as sluggish as the GUIs you mention since it's HTML5? Is the benefit from only rendering a subset or something? I'm struggling understanding how rendering a page into a terminal is faster than just rendering to a regular window. It just seems like another layer between the browser and the GPU.
I think you have a misunderstanding of the full system. Like you are thinking the GUI is much simpler than it actually is. Conversely I think you're thinking that CLIs are much more complicated. There's a lot more going on than just painting pixels on the screen. Maybe start by asking why vim is several magnitudes less resource intensive then Microsoft word. Then ask the same about neomutt vs Thunderbird vs outlook/Apple Mail
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?
I understand that a GUI is complex, which is why I'm confused about the performance benefit as HTML5 already acts like a GUI. Even if it's a terminal program, it would still need to calculate the layout and handle the DOM to remain compliant, no? A website can be as intensive as Word.
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.
Use SSH’s dynamic proxy mode (-D) so you have the full browser running locally and only the network traffic running over SSH.
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.
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.
Too bad Rust compiles with LLVM (C++) and the stdlib links to glibc (C) then.
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.
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.
I wanted to like modal editing in Emacs. But I had to come to terms with the fact that it's always going to be a kludge. Boon is the best I've seen it get, but when I wanted to improve it, I realized it would be less work over the long run to just make my own text editor, though that's mostly because my chosen language, ruby, just doesn't have very good tooling yet.
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.
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.
You're right, I think I misheard that on some YouTube video. There's a discussion on the ghostty repo, and someone said presenterm had something though.
The good thing is that the image renderer definitely works on ghostty!
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
Yeah that seems like an area for improvement in Godot's GUI system indeed. For my stuff, I never had a need for theming, but good to keep in mind if one ever wanted to do an app shared with others.
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..
Release build of such a Godot-built tool is between 60-70 MB. Other than that, it seems fast enough & RAM-friendly enough for the usual simple use-cases. Game engines tend toward self-optimization over time.
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.
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.
TurboPascal springs to mind because I know someone who made a video store management system with all kinds of forms and screens (via Turbo Vision[0]) in the early 90s.
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.
> 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.
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.
X11 transports just fine over SSH. You can have a window in your own desktop that is drawn by a process running remotely, and it looks and feels just like it is local.
Is Wayland really that bad though? I switched from Awesome to Hyprland, and the gaming support (VRR, HDR), among other things is much more straightforward. For normal desktop usage, I haven't seen much of a difference. Certainly not a negative one.
Wayland completely punted on the remote display capabilities of X11. There has been no effort to replicate this functionality. If you switch to Wayland, you can no longer run GUI apps through SSH.
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.
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.
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.
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.
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 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.
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?
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.
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.
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…
Back in the olden times (2009) I was working for a company trying to sell advertising devices (screens on buses) with a fancy* HTML interface for setting up/controlling/reporting etc. to Titan. Except all the Titan operators hated it because their old system - an old TUI - was about a million times faster for them to use (not just because they were used to it but it didn't require a mouse, etc.) than the fancy* HTML (which was, to be fair, bloody awful but not my fault.)
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.
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.
I don't know what I just got into, but I love it. Reminds me of Hattrick (the decades old soccer management sim) but with more elbow grease and panache. If you're even remotely interested, just ssh in and you're off to the races.
BTW, the video at the top of the repo readme won't open on any device I own.
Looks really cool! Love the artwork. Right now the video in the readme doesn’t render on github, though. I had to manually download the mp4 from your demo folder to view it.
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.
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.
That's a good point! Some sort of widget framework is important for extensions. But I think my issue is that there are only a dozen included widgets, so very basic things are left to third parties. Most mature UI libraries would include all the basic things, and leave a widget interface for uncommon extensions, not rely on third parties for basic features.
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.
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
I understand that and am usually comfortable with it, but as far as Rust goes this goes too far for me. I'm fine taking on lots of deps for a big feature like Ratatui. But taking on a new dep for each widget seemed excessive.
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.
How is the Windows support in Ratatui? I recently developed something with a different library (also crossterm based) only to discover it did not work very well for my windows users and ended up having to build a GUI with Iced.
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.
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.
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++.
Even worse than C++? That has never been my experience. I maintain C++ projects that take hours to build from scratch. Most Rust projects I install, even the very big ones, are ~3-5min max.
Are you building in release or debug? Do you have lto enabled? Rust compile time is absolutely worse than c++, and I'm not sure many in the community would disagree. You need to aggressively split large crates up to make it sane. A lot of this comes down to the fact the crate is the compilation unit rather than individual files.
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 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,..).
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.
I began learning Rust in my spare time - as a C++ dev it seemed like the right thing to do. I ended up using Ratatui for a hangman implementation. I really liked using it, I ended up with an itch to make an oldschool roguelike with it. Perhaps some day I'll carry on and do it.
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
This is basically how dioxus 0.7.0 works. You can download components, and they will automatically add the source to your source and then you can just freely use them
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.
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 recently asked grok-code-fast-1 to read the SST OpenTUI readme and docs (gave it the github link), and to write an implementation plan for an OpenTUI usage mode for my Rust CLI stdin/stdout app. It fetched the readme. Fetched a couple more doc pages. Response begins "Sure, here's the plan: I'll write a TUI using the Rust package Ratatui..."
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.
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.
Also once your workflow is increasingly keyboard based (like when using a tiled window manager), TUIs just make more sense.
Every GUI I replace with a TUI is one less flow-breaking obstacle where I have to suddenly reach for the mouse.
Other benefits:
1. Consistent font and sizing. Pick the font you find easiest to read and set it in the terminal, now all TUI apps use it at the correct size.
2. Consistent theming. TUI apps use the same color scheme as your terminal, as your vim, etc. A consistent "desktop" is less distracting. Especially when you don't have to deal with crappy Electron apps displaying animations and ads (looking at you Discord).
3. Efficient on screen real-estate. Most TUI apps don't waste a lot of space on "padding", "giving elements space to breathe" or other "correct UX patterns". They tile nicely.
4. Never and issues copy and pasting. I used a GUI chat app recently that wouldn't let me select text, seriously.
5. Did I mention they are fun to use and relatively easy to develop?
Yeah they all use the same palette, but they don't all use the palette the same way.
And copy / paste, "hm does this TUI intercept mouse clicks, ah it does, oh what was the key combo for my terminal emulator that allows to skip that? Crap I pressed ctrl-c instead of ctrl-shift-c". Or worse when you want to select text in a column-based TUI and your terminal emulator doesn't have any sort of column-selection handling.
And built in remote use via SSH.
Well-designed GUIs can be fully keyboard operated, where the mouse-driven interface only serves as a way to educate the user about which functionality is available. I'll use Tera Term (a serial terminal emulator) as an example. If you want to start a serial XMODEM transfer, you can figure out how to do it just by clicking around the user interface. You click on "File", then "Transfer", then "XMODEM", then "Send". Once you do it a few times, you remember the layout of the menus, and can start navigating solely by keyboard. Instead of "breaking your flow" by having to reach for the mouse, you just hold down Alt and type "FTXS". This is much faster, and you learned how to do it entirely from just using the program and observing which letters are underlined in the menus. There's no need to look at a manual or help page.
A well-designed TUI and GUI have great keyboard nav, discoverability, UX, and all. The question is more about what you want for the 99% of UIs that aren't well-designed nor polished, and what kind of worst-case you want to deal with.
By default, TUIs have bad discoverability unless the developer puts in the effort. But at least you have keyboard navigation and run in a terminal.
By default, GUIs have bad keybindings unless the developer puts in the effort. In the worst case they aren't even kb navigable. But at least they tend to be discoverable.
I think my low-key long-term goal is to eventually fully eliminate the mouse while still enjoying the niceties of a modern GUI desktop.
Going to shill for the Ultimate Hacking Keyboard here, specifically its mouse-keys capability, which is where I can move the mouse via WASD (or any other binding). I have both the touchpoint and trackball add-on modules, but I still use mouse keys to manipulate my cursor 99% of the time.
they do not, GUI is more capable of handling keyboards than TUI because terminals still have pretty dumb limitations where some modifiers aren't even visible/bindable!
This seems trivially false or disconnected from the important part of what I'm referring to here.
TUIs have to be navigable by keyboard. They could be garbage in every other way, but at least they have that.
GUIs might have keybindings as polish if the developers put in the effort. Otherwise they either don't have keybindings, or they rely on generalized keybindings that come with the OS/UI toolkit that can be bad/impossible in arbitrary ways, like if tab is swallowed by an input so you can't even tab past a component or dismiss a modal. Or the only GUI is inside a web browser.
This seems trivially false to you because you don't rise above the trivial, but also forget about similar trivial fails in TUIs.
> They could be garbage in every other way, but at least they have that
Not really, they could also not implement keyboard input for some interactions and only react to mouse. You could have a click-to-open-url in your terminal without a keyboard fallback setup. Of course, you could set it up, but that would be "polish if you put in the effort" There is no limit to garbage.
> Also once your workflow is increasingly keyboard based (like when using a tiled window manager),
Exactly, for example, you've set your Windows key to be reponsible for all window-based movements, so you have it move/resize app windows and want to have the same key help you move/resize "inner windows/panes/columns" in a TUI app. Well, tough luck, the terminal doesn't even recognize this modifier!
Again, "as polish if you put in the effort" you can achieve anything via some external remapping to supported keys, but "otherwise" you don't have keybindings, and don't even have generalized fallback common (though not universal, again, there is no limit to garbage) to GUIs.
Or you'd be unable to bind some key combo because in a terminal that key combo is equivalent to regular typing and you need to timeout to differentiate between the two, so a permanent friction.
> tab is swallowed by an input so you can't even tab past a component
Of course you can, use your keyboard to move the mouse pointer and click outside of the input field. All pure organic keyboard-based interaction! "They could be garbage", but at lest you have that keyboard-based option (yes, only "polish/put in effort")
I've used some pretty bad ncurses apps that barely have keybindings, like oterm.
I'd probably put them in a third, discarded, mutant category where they are mouse-first applications that run in the terminal. Thus like GUIs, keyboard-support is bolted on.
So a better distinction here is mouse-first vs keyboard-first, but I think "TUI vs GUI" is close enough to that and it kinda stands in for that distinction in most cases.
Vim, tmux, and weechat would be examples of keyboard-first TUIs where mouse support is bolted on as polish, but never required.
Where you lose me is that every example you can think of where a bad TUI might not perfectly mesh into a keyboard-only workflow, the GUI counterparts to that example is much worse. So we would just agree that it's a bad TUI rather than anyone going "you're right, the average GUI is much better if keyboard-driven control is my priority".
I don't understand some of your examples though. Your super key is always at a global level that you wouldn't expect apps to read, that's the point. And using timeouts to handle keybinding collisions or something? Dunno what that looks like nor why you would do it. The examples are like if I said GUIs suck because it's a dreadful experience if you insist on using your mouse upside down.
> So a better distinction here is mouse-first vs keyboard-first, but I think "TUI vs GUI" is close enough to that and it kinda stands in for that distinction in most cases.
It's indeed a better distinction, but no, TUI vs GUI is nowhere close, specifically for your explicitly mentioned use case of "workflow is increasingly keyboard based" because that's exactly where GUI shines as it has much fewer fundamental limitations in keyboard handling.
> than anyone going "you're right, the average GUI
That's your strawman framing, why would I care about "the average"? It's not a limit for anyone, one can always choose a better-than-average app. My point is that at the top there is no comparison because TUIs offer nothing and have much bigger fundamental limitations. So of course with the wrong framing you can find worse examples.
> And using timeouts to handle keybinding collisions or something? Dunno what that looks like nor why you would do it.
Terminals send Esc for Alt-X combos, so to differentiate those combos from a single Escape press you need to track timers (if no extra key signal, then it's Esc, if another key signal, then it's a combo). And Esc is one of the most used keys in e.g. Vim
> Your super key is always at a global level that you wouldn't expect apps to read, that's the point.
Of course I would! What I wouldn't expect is for the app to override any global OS function bound to that key, but I would definitely expect to be able to not waste a whole thumb-conveniently located modifier just because
That's very close to my point - you're used to some trivial keyboard workflow, so wasting the whole modifier is just fine, you can't even comprehend why someone wouldn't want that, it's like a mouse upside down!
IMO, the value in TUIs lie in 1) Composability: we've got really good tools for manipulating terminal windows like tmux, :term in vim, etc, whereas the same can't really be said for OS-level windows and 2) As a shibboleth: They implicitly state that they're built by and for keyboard-centric technical users, and thus the wants and needs of keyboard-centric technical users are going to be the valued over the wants and needs of the lowest common denominator. 3) They look cool.
1. if you use some external window manager tool, what workflow does tmux/term provide you that OS-level windows with that tool do not?
2. specifically for "keyboard-centric tech users" that's a big fail since the terminal platform is not capable of supporting advanced keybindings presisely because all they do is "target the lowest common denominator" (as defined in 1965) of keybinding support!!! So your cool setup from a GUI code editor is simply not transferrable.
3. this is very rare, I mean, just look at the screenshots, a lot of them couldn't even add non-gapped borders=== ---!
1. I think the fact that you refer to "some external window manager tool", whereas you know the name tmux off the top of your head illustrates that first point.
2. Again, it's not about the possible capabilities. Objectively, GUI programs contain a superset of possible TUI programs (since your GUI program could be a terminal emulator). It's about it being a shibboleth: I can be pretty confident that the TUI application will have a keyboard-based workflow, and I can be pretty confident that the TUI application will be targeting a technical user base, because those are the only people building and using TUI tools. The "lowest common denominator" in that sentence was referring to the users not the systems.
1. I think the fact that you have nothing of substance and have to read into the fact that after reading your comment explicitly mentioning tmux I repeated that illustrates the point is invalid.
2. but what's the value of a shibboleth if it's not reflected in capabilities??? Why would you care that a TUI app targets "tech user base" if you also know it will be less capable in your 'keyboard-centric' workflow due to platform limitations? And LCD for users just doesn't make sense, what user quality are you min-aggregating?
Maybe in theory, but in practice they literally all fail at that.
Every text editor and most professional apps have elaborate hotkey schemes in practice, though. It's a matter of target audience and developer intent. There's nothing special about TUIs in regards to keyboard driveability, and they're heavily limited in just about every single way I can think of. Which is the main reason most TUI apps are simple and small utilities.
The very nature of being simple makes it so that the amount of hotkeys you have to learn is limited.
While most gui ones also have hotkeys, most people only remember a tiny selection and have to rely on navigating menus and dialogs to access stuff they can't remember which makes their usage very slow.
It depends on the goal, e.g. software like Maya is built for the world in which the amount of required work makes even average projects intractable if you're slow with your tools. Entire generations of actual masters of their craft have built their careers on being efficient with it.
Menus are also not slow by any measure, they're only needed for discoverability, can be navigated with the keyboard as well, and aren't that different from the menus many TUI apps have (e.g. Midnight Commander). Moreover, there are real novel ideas like Microsoft's ribbon, which basically combine vi-style input and discoverability. Hotkeys is just one way to drive a GUI app using the keyboard, out of many.
Anecdotal evidence here. My use-case needs some UI, but a full blown GUI is way, way overkill.
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.
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.
To be fair, TUIs are strictly worse accessibility-wise than GUIs.
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.
What you say is true, but TUIs are not strictly worse than GUIs at accessibility. The fact that text is inherently more legible than graphics means that, for example, blind players can play console-based roguelikes (and do: https://www.rockpapershotgun.com/playing-roguelikes-when-you... ), and Dungeon Crawl Stone Soup even has configuration options to improve the experience for blind people: https://github.com/crawl/crawl/blob/599108c877da33bc03cb73da...
Text isn't more legible without structure, and without communicating structure, which is what various accessibility toolkits do, you don't get this supposed benefit
Text has inherent structure that GUIs don't. The ceiling for GUIs is higher (thanks to standards and supporting frameworks), but the floor for TUIs is higher.
Ok, what is the inherent structure of these two columns and how is a screen reader supposed to divine that structure without the framework telling it that there are 2 headers with the following text? And imagine the layout is space-separated as in cli utils
C| Column Wide |
o| |
l||
1|2|
Even at the worst case, text can be read aloud and give some indication of what the screen contains. This is absolutely not true for a GUI which could easily just be an opaque rendered canvas. The fact remains: TUIs are inherently legible in ways that GUIs are not guaranteed to be.
Both false: you'll have NO indication if you read letters from different words out of order! You'll not understand whether 'o' is a value or a continuation of the column name even in the primitive example above, and for anything even remotely complicated it's even worse.
> 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
Plus there's no reason why most GUI's can't adopt a keyboard-only workflow. It's easy to implement. The inverse is not true.
There has to be a reason when 99% of GUI apps don't support it.
There are ways to do it in most GUI applications. On Windows, pressing Alt will sometimes show you the combination to activate certain parts of the UI (keyboard accelerators). It's not obvious anymore because people don't focus on accessibility. Sadly, it's not common practice to ensure a good workflow, because it's assumed that they will use a mouse. Or people keep re-inventing TUI every time they think they want a terminal-friendly utility.
What are you talking about, a screen reader out to be way more capable in a TUI or CLI than the massive pain of ANDI or 508 compliance.
TUIs still need to comply with 508 so that “massive pain” is there either way.
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.
You physically can't do any of this in a TUI.
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.
> In addition they cause other difficulties, like testability, i18n, l10n and accessability.
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.
Where I think TUIs had a niche GUIs don't quite reproduce is in the very particular way DOS TUIs processed input.
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.
> I think writing a useful GUI has considerable overhead no matter which technology you use.
I find egui far easier than Ratatui.
"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."
I strongly disagree with this. Obviously Rust hasn't had the decades of life that C/C++ has to give you weird niche libraries, but at this point the Rust crate ecosystem is huge and you have to go fairly niche before you find something where there simply isn't a Rust option. Usually you find something and it's a lot nicer than the C option.
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.
This is surprising to hear; my experience matches the parent comments' exactly. The crates exist, but are usually toys that haven't been applied to practical problem. This is a generalization, but it applies well in many domains. Often, they're someone's one-off school project, a "let's build X in rust" from someone who doesn't have a practical use case for X etc.
I'm going to agree with you here. I love rust, but this is a big down side. I have to do so much ecosystem building and low level stuff because the libs available don't exist, or are not in a suitably usable state.
Do you happen to have any particular examples?
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.
IMO, traditional GUI frameworks in Rust (like Qt) are difficult for the same reason that game engines in Rust are difficult: cyclical references. A window might contain a group box which contains a text field and a button. All of these are (direct or indirect) children of the window, but all children also hold a reference to their parent. Qt's signal-slot mechanism would also be difficult to implement in Rust.
Why not just use Arc and clone the cyclical references as much as you want `button: RefCell<Option<Arc<Button>>>`?
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, but they basically reinvented the wheel for everything they did, because the existing GUI stuff in the rust ecosystem sucked so badly it wasn't worth fixing.
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.
Yeah and even then they have a ton of rendering and performance issues. GUI frameworks are just incredibly hard to do right, and take a ton of time.
I'm betting on Slint. I kind of hated QML but it looks like they have learned a lot of lessons.
I evaluated gpui for a project I’m working on. While I’ve found the rendering and performance to be great (and actually switched to Zed as my daily driver after playing with it), the (absence of an) accessibility story made me grudgingly just use tauri.
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 think they wanted more control over the GUI, so the best answer to that is build something that you have 100% control over. In one of their first blog posts they explain more in deep the reasons.
> 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
I'm glad they contributed something fantastic to the Rust GUI system, but I don't think this is fair: EGUI is fantastic.
I have used egui in actual projects. It is slow, opinionated in a bad way, not very customizable in terms of themes, and definitely not up to date in terms of latest GUI standards. It isn’t even the best RUST GUI project by any of those metrics.
Interesting! I am using it in some complex stuff with 3D graphics (A structural biology/molecular dynamics tool), and it is a great experience. I need to compare it to GPGUI and Slint; would love to compare the pros and cons first-hand.
I love how Slint works on embedded devices too.
As I said above, they all suck in some way. It's a matter of deciding what is most important to you and picking the one that sucks least for that.
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.
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
they recently opensourced https://www.gpui.rs/ which is basicly the ui code pulled into its own framework
Why does that link redirect to a fart sound hosted on Wikipedia?
I find it always hilarious when websites check the referer for HN and do some random shit. "Alive internet theory"
The author doesn't like HN.
This is sort of thing is why I have a “they don't want me there, and I'm fine with that” list in my PiHole config.
The Referer header strikes again. You'd think the typo in its name would be the worst thing about it, but nope.
A quick glance at the website in question suggests that its owner may not be particularly mentally mature.
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!
> Rust is simply not meant for GUI-based data design
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.
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.
Cosmic DE is written in Rust, it's nice and is a good proof you can do GUI in Rust quite well
Given Qt consists of hardcore lovers of old C++, this is unlikely to happen in this generation.
They literally announced that they are working on it: https://www.qt.io/qt-bridges
There's already a very good bridge for Qt: https://kdab.github.io/cxx-qt/book/
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.
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.
Doesn't https://github.com/longbridge/gpui-component tick all your boxes ?
Does it work without a modern GPU?
Seriously, there is requirement to CPU draw UI components too ? OP didn't say that and it sounds crazy anyways. Even your point-of-sale terminal units with displays have integrated GPUs. Popular Ex in 2025: Qualcomm Snapdragon 810 SoC (octa-core ARM) with Adreno 430 GPU.
I mean if it requires a modern GPU, that leaves a ton of perfectly working older hardware out in the dust, even those with a GPU if they don't support modern APIs. That's a huge downside when the competing toolkits run just fine on the CPU.
> People keep asking why TUIs in Rust
Because it is quite easy to do.
There are also TUIs in other languages, just Rust is more cool.
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...
When I went to go look for a platform to implement a personal text editor on, I somewhat quickly settled on the vt100 terminal api with kitty extensions, particularly its keyboard protocol. Everything else locks you into, not only a language, everybody codes frameworks these days, nobody writes apis, but also what's essentially already a legacy solution, a framework is going to get updates at the speed of the developer's passion.
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.
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.
there is this new library: https://longbridge.github.io/gpui-component/
"Maybe one day an AI bro who pays for Twitter will contribute something positive to society, but this is not that day."
Haha!
What about Iced or libcosmic (based on Iced)?
Wrong link? My browser (Firefox on iOS) redirects me to a fart sound media [1], and going back in history takes me back to here.
[1]: https://upload.wikimedia.org/wikipedia/commons/d/d4/Human_fa...
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 just completely disagree. We have Slint, Dioxus, Tauri, Egui (best imo). If Dioxus blitz renderer takes off them it will vastly better than 99% of options for other languages
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?
Character based interfaces are just nice, IMHO. The Borland IDE was the pinnacle of dev interfaces IMHO. It updated to have modern language server support etc would be my dream dev environment. It would be cool to see how far a compliant web browser could be taken in text mode. It's really sad that most terminals don't have proper image support, btw.
Edit: A comment here linked to https://www.brow.sh/ It looks amazing.
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/
Wouldn't you still be as sluggish as the GUIs you mention since it's HTML5? Is the benefit from only rendering a subset or something? I'm struggling understanding how rendering a page into a terminal is faster than just rendering to a regular window. It just seems like another layer between the browser and the GPU.
I think you have a misunderstanding of the full system. Like you are thinking the GUI is much simpler than it actually is. Conversely I think you're thinking that CLIs are much more complicated. There's a lot more going on than just painting pixels on the screen. Maybe start by asking why vim is several magnitudes less resource intensive then Microsoft word. Then ask the same about neomutt vs Thunderbird vs outlook/Apple Mail
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?
I understand that a GUI is complex, which is why I'm confused about the performance benefit as HTML5 already acts like a GUI. Even if it's a terminal program, it would still need to calculate the layout and handle the DOM to remain compliant, no? A website can be as intensive as Word.
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.
Just less overall overhead
Word has no business being as intensive as it is. It is a bloated piece of garbage.SSH access over a slow network connection?
Use SSH’s dynamic proxy mode (-D) so you have the full browser running locally and only the network traffic running over SSH.
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.
Why not proxy the network calls only then and use a real browser?
[dead]
Browsh [0] - it runs firefox headless, and renders everything to ascii in the terminal
It's glorious
[0] https://www.brow.sh/
> 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.
I believe they wants text browser written specifically in rust, and does not want to touch any software written in filth like c/c++.
Too bad Rust compiles with LLVM (C++) and the stdlib links to glibc (C) then.
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'm sorry, did you even read my comment?
I mentioned those by name...
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
Chawan is great. Very customizable. Regular updates. Fast. The chaman utility replacing man is also good
Not rust, but check out nimwave: https://github.com/ansiwave/nimwave
Carbonyl looked promising but unfortunately is not maintained anymore: https://github.com/fathyb/carbonyl
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.
I wanted to like modal editing in Emacs. But I had to come to terms with the fact that it's always going to be a kludge. Boon is the best I've seen it get, but when I wanted to improve it, I realized it would be less work over the long run to just make my own text editor, though that's mostly because my chosen language, ruby, just doesn't have very good tooling yet.
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.
Probably not as limited as you think
https://notcurses.com/
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:
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.
This is very cool, thanks for sharing! p.s. I don't think Ghostty implements this protocol (yet?)
You're right, I think I misheard that on some YouTube video. There's a discussion on the ghostty repo, and someone said presenterm had something though.
The good thing is that the image renderer definitely works on ghostty!
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
Yeah that seems like an area for improvement in Godot's GUI system indeed. For my stuff, I never had a need for theming, but good to keep in mind if one ever wanted to do an app shared with others.
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..
Godot is a heavy dependency for making small tools, no?
Release build of such a Godot-built tool is between 60-70 MB. Other than that, it seems fast enough & RAM-friendly enough for the usual simple use-cases. Game engines tend toward self-optimization over time.
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...
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.
TurboPascal springs to mind because I know someone who made a video store management system with all kinds of forms and screens (via Turbo Vision[0]) in the early 90s.
[0] https://en.wikipedia.org/wiki/Turbo_Vision
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.
This series? https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
Also https://github.com/withoutboats/notty
> 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.
X11 transports just fine over SSH. You can have a window in your own desktop that is drawn by a process running remotely, and it looks and feels just like it is local.
We gave up X11 for the unfulfilled promise of something greater. A tech tale as old as time.
Is Wayland really that bad though? I switched from Awesome to Hyprland, and the gaming support (VRR, HDR), among other things is much more straightforward. For normal desktop usage, I haven't seen much of a difference. Certainly not a negative one.
Wayland completely punted on the remote display capabilities of X11. There has been no effort to replicate this functionality. If you switch to Wayland, you can no longer run GUI apps through 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
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.
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.
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.
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
Good idea. Fixing this in https://github.com/ratatui/ratatui-website/pull/979 Disclaimer, I work on Codex since about a month ago.
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.
Or Claude. There are more than a few developers on my team that prefer terminal interface for their codegen chatbots.
Sure, but Claude isn't written in Rust and doesn't use Ratatui.
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.
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.
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.
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.
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.
Back in the olden times (2009) I was working for a company trying to sell advertising devices (screens on buses) with a fancy* HTML interface for setting up/controlling/reporting etc. to Titan. Except all the Titan operators hated it because their old system - an old TUI - was about a million times faster for them to use (not just because they were used to it but it didn't require a mouse, etc.) than the fancy* HTML (which was, to be fair, bloody awful but not my fault.)
Sounds unholy! I think the only people who disparage TUIs haven't used one!
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.
The dutch teletekst has a SSH interface, which is also made with ratatui [1].
ssh teletekst.nl
[1] https://tweakers.net/geek/237754/nos-maakt-teletekst-beschik...
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'?
First in debug, then I built in release to see if that changed something, but it didn't.
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.
Thanks! I will definitely have a look at this. I really want to like Ratatui but I do wonder how much bloat there is
(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.
Shameless plug of my TUI game, also built with Ratatui
https://github.com/ricott1/rebels-in-the-sky
I don't know what I just got into, but I love it. Reminds me of Hattrick (the decades old soccer management sim) but with more elbow grease and panache. If you're even remotely interested, just ssh in and you're off to the races.
BTW, the video at the top of the repo readme won't open on any device I own.
Ja, I know, it's a coin flip, sometimes it works :( I added a youtube link just below it, it's the demo
> P2P terminal game about spacepirates playing basketball across the galaxy
Absolutely fantastic description right there.
Looks really cool! Love the artwork. Right now the video in the readme doesn’t render on github, though. I had to manually download the mp4 from your demo folder to view it.
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.
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.
That's a good point! Some sort of widget framework is important for extensions. But I think my issue is that there are only a dozen included widgets, so very basic things are left to third parties. Most mature UI libraries would include all the basic things, and leave a widget interface for uncommon extensions, not rely on third parties for basic features.
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.
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
I understand that and am usually comfortable with it, but as far as Rust goes this goes too far for me. I'm fine taking on lots of deps for a big feature like Ratatui. But taking on a new dep for each widget seemed excessive.
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.
Don't all the major coding agents have CLI mode now? Cline CLI. Opencode CLI. Codex CLI. Gemini CLI. Claude Code CLI. Etc.
Related from yesterday:
Bluetui – A TUI for managing Bluetooth on Linux
https://news.ycombinator.com/item?id=45817114 https://github.com/pythops/bluetui
How is the Windows support in Ratatui? I recently developed something with a different library (also crossterm based) only to discover it did not work very well for my windows users and ended up having to build a GUI with Iced.
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.
I use gitui on Windows and it is amazing, though mostly from a git bash shell.
I’d definitely use something like this too, but don’t have the luxury of telling my end users to.
They’re very nontechnical.
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
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++.
Even worse than C++? That has never been my experience. I maintain C++ projects that take hours to build from scratch. Most Rust projects I install, even the very big ones, are ~3-5min max.
Are you building in release or debug? Do you have lto enabled? Rust compile time is absolutely worse than c++, and I'm not sure many in the community would disagree. You need to aggressively split large crates up to make it sane. A lot of this comes down to the fact the crate is the compilation unit rather than individual files.
It would appear that when actually measured head to head, compile times are approximately the same: https://quick-lint-js.com/blog/cpp-vs-rust-build-times/
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.
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,..).
Aren’t all of these in a sense personal projects? If it works for the developer, that’s enough.
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.
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.
I began learning Rust in my spare time - as a C++ dev it seemed like the right thing to do. I ended up using Ratatui for a hangman implementation. I really liked using it, I ended up with an itch to make an oldschool roguelike with it. Perhaps some day I'll carry on and do it.
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
fzf is Go. There is Skim, which is done in Rust.
Nice. It would be also cool if they add 'cargo install %tool%' commands for each one.
This is basically how dioxus 0.7.0 works. You can download components, and they will automatically add the source to your source and then you can just freely use them
https://dioxuslabs.com/components/
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.
Ratatui is awesome, but I haven’t found a widget library and event loop that I like, so had to roll my own.
Any recommendations for something that’s ergonomic to use and looks nice?
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.
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
https://posting.sh/
xh has sessions. https://github.com/ducaale/xh
Very dope. I really like dua as my mac only has 256 GB.
There are some truly gorgeous TUIs in that list
I recently asked grok-code-fast-1 to read the SST OpenTUI readme and docs (gave it the github link), and to write an implementation plan for an OpenTUI usage mode for my Rust CLI stdin/stdout app. It fetched the readme. Fetched a couple more doc pages. Response begins "Sure, here's the plan: I'll write a TUI using the Rust package Ratatui..."
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