Ratatui – App Showcase

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.

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

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.

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.

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.