Live data from Hacker News

Ratatui – App Showcase

ratatui.rs

181–190 of 238 posts

Re: Ratatui – App Showcase

#181
post #50

Earlier quoted context omitted.

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 c…

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

Re: Ratatui – App Showcase

#182
post #167

Earlier quoted context omitted.

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

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.

Re: Ratatui – App Showcase

#183

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…

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.

Re: Ratatui – App Showcase

#184
post #172

Earlier quoted context omitted.

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.

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.

Re: Ratatui – App Showcase

#185

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…

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

Re: Ratatui – App Showcase

#186

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…

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

Re: Ratatui – App Showcase

#187
post #172

Earlier quoted context omitted.

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.

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!

Maybe in theory, but in practice they literally all fail at that.

Re: Ratatui – App Showcase

#188
post #174

Earlier quoted context omitted.

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.

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

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.

Re: Ratatui – App Showcase

#189

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 yo…

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.

Re: Ratatui – App Showcase

#190
post #72

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 yo…

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?

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

[0] https://notcurses.com/

Post reply on HN