[HN Gopher] Ratatui - App Showcase
___________________________________________________________________
Ratatui - App Showcase
Author : AbuAssar
Score : 694 points
Date : 2025-11-06 02:50 UTC (20 hours ago)
(HTM) web link (ratatui.rs)
(TXT) w3m dump (ratatui.rs)
| dkdcio wrote:
| 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
| dkdcio wrote:
| I am also now curious about alternatives/what differentiates
| this crate
| airstrike wrote:
| 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
| wrs wrote:
| I think they're saying this crate is _why_ Rust is experiencing
| a TUI revolution.
|
| Charm would probably say the same for Go.
| qudat wrote:
| 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
| kstrauser wrote:
| What's an SSH app vs a terminal app?
| moooo99 wrote:
| 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/
| hnlmorg wrote:
| Any terminal app can be an "ssh app". There isn't really
| a distinction.
| tomhow wrote:
| 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._
| omarvanez wrote:
| 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
| morkalork wrote:
| IMO it's like seeing kids bust out disposable kodak cameras at
| the bar: generational nostalgia
| baq wrote:
| 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...
| backscratches wrote:
| TUIs work better than GUIs. So much more powerful with so
| many less resources.
| zimpenfish wrote:
| 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.)
| backscratches wrote:
| Sounds unholy! I think the only people who disparage TUIs
| haven't used one!
| CSSer wrote:
| 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?
| DC-3 wrote:
| 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.
| genidoi wrote:
| 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...
| eschaton wrote:
| 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.
| zimpenfish wrote:
| 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
| flomo wrote:
| 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.
| wonger_ wrote:
| This series? https://arcan-fe.com/2025/01/27/sunsetting-
| cursed-terminal-e...
| speed_spread wrote:
| Also https://github.com/withoutboats/notty
| crazyloglad wrote:
| 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.
| lynndotpy wrote:
| In addition to other comments, it's the only real way to make a
| usable GUI-like experience over SSH.
| vostok wrote:
| I've generally had good experiences with the various
| compressed X11-like tools. One example is x2go, but there are
| a few.
| fragmede wrote:
| 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.
| MangoToupe wrote:
| You can also serve a window server over ssh
| adastra22 wrote:
| 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.
| aj_hackman wrote:
| We gave up X11 for the unfulfilled promise of something
| greater. A tech tale as old as time.
| seanw444 wrote:
| 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.
| webnrrd2k wrote:
| 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.
| laserbeam wrote:
| > 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.
| dualogy wrote:
| 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
| bodge5000 wrote:
| 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
| dualogy wrote:
| 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..
| dlivingston wrote:
| Godot is a heavy dependency for making small tools, no?
| dualogy wrote:
| 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.
| orbital-decay wrote:
| 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.
| nurettin wrote:
| 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.
| tptacek wrote:
| High-level languages that compile to single binaries, and very
| good TUI frameworks (maybe inspired by Python Textual?) for
| them.
| travisgriggs wrote:
| > 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.
| alwillis wrote:
| > 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.
| positron26 wrote:
| 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.
| Szpadel wrote:
| 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
| mock-possum wrote:
| Or Claude. There are more than a few developers on my team
| that prefer terminal interface for their codegen chatbots.
| adastra22 wrote:
| Sure, but Claude isn't written in Rust and doesn't use
| Ratatui.
| serial_dev wrote:
| 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.
| mendelmaleh wrote:
| 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.
| J_Shelby_J wrote:
| 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.
| pixelready wrote:
| 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_gipsy wrote:
| 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.
| CSSer wrote:
| 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.
| AceJohnny2 wrote:
| 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".
| CSSer wrote:
| 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.
| dwattttt wrote:
| If you have the Rust toolchain installed, installing is as
| simple as e.g.: cargo install ripgrep
|
| 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.
| smartmic wrote:
| 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++.
| adastra22 wrote:
| 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.
| surajrmal wrote:
| 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.
| adastra22 wrote:
| 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/
| skydhash wrote:
| 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,..).
| mariusor wrote:
| > 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.
| Jaxan wrote:
| Aren't all of these in a sense personal projects? If it works
| for the developer, that's enough.
| nullbyte808 wrote:
| Very dope. I really like dua as my mac only has 256 GB.
| siavosh wrote:
| 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.
| seabrookmx wrote:
| 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
| bitexploder wrote:
| 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.
| tcoff91 wrote:
| Kulala nvim plugin or emacs rest client
| esafak wrote:
| xh has sessions. https://github.com/ducaale/xh
| esseph wrote:
| https://posting.sh/
| tonypapousek wrote:
| Most popular? https://justuse.org/curl/
| ModernMech wrote:
| 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.
| speed_spread wrote:
| 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.
| ModernMech wrote:
| 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.
| bbkane wrote:
| 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
| ModernMech wrote:
| 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.
| mbm wrote:
| Ratatui is awesome! Just built a little chat client with it, tons
| of fun.
|
| https://terma.mattmay.dev/
| godelski wrote:
| 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.
| fruitworks wrote:
| 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
| awesomeusername wrote:
| Browsh [0] - it runs firefox headless, and renders everything
| to ascii in the terminal
|
| It's glorious
|
| [0] https://www.brow.sh/
| be_erik wrote:
| I use this one pretty often. It's great. https://chawan.net/
| godelski wrote:
| This actually looks pretty reasonable. Thanks! I'll
| definitely be giving it a try
| moderation wrote:
| Chawan is great. Very customizable. Regular updates. Fast.
| The chaman utility replacing man is also good
| littlestymaar wrote:
| > 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
| jasonjayr wrote:
| ELinks is the TUI browser I've used since .... forever.
|
| https://github.com/rkd77/elinks
| xvilka wrote:
| 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.
| godelski wrote:
| I'm sorry, did you even read my comment?
|
| I mentioned those by name... >> I know
| there's some browsers but things like W3M, Lynx, or *links*
| are... rough...
| ororoo wrote:
| I believe they wants text browser written specifically in
| rust, and does not want to touch any software written in
| filth like c/c++.
| littlestymaar wrote:
| 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.
| gf000 wrote:
| 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?
| selfhoster11 wrote:
| SSH access over a slow network connection?
| gf000 wrote:
| Why not proxy the network calls only then and use a real
| browser?
| acdha wrote:
| 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.
| actionfromafar wrote:
| 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.
| godelski wrote:
| > 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/
| globular-toast wrote:
| 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.
| vinceguidry wrote:
| 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.
| godelski wrote:
| Probably not as limited as you think
|
| https://notcurses.com/
| miguel_martin wrote:
| Not rust, but check out nimwave:
| https://github.com/ansiwave/nimwave
| RustSupremacist wrote:
| 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.
| goku12 wrote:
| 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.
| dancemethis wrote:
| 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.
| ogoffart wrote:
| 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...
| OtomotO wrote:
| 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.
| vinceguidry wrote:
| 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.
| lenkite wrote:
| Doesn't https://github.com/longbridge/gpui-component tick all
| your boxes ?
| Narishma wrote:
| Does it work without a modern GPU?
| sunbum wrote:
| Why does that link redirect to a fart sound hosted on
| Wikipedia?
| heavensteeth wrote:
| The author doesn't like HN.
| dmit wrote:
| The Referer header strikes again. You'd think the typo in
| its name would be the worst thing about it, but nope.
| dspillett wrote:
| 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.
| bakugo wrote:
| A quick glance at the website in question suggests that its
| owner may not be particularly mentally mature.
| GaggiX wrote:
| I find it always hilarious when websites check the referer
| for HN and do some random shit. "Alive internet theory"
| SpikedCola wrote:
| // 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
| clanaEUR(tm)s wisdom be yours: // // Never
| read Hacker News // - Aphyr, "Hexing the technical
| interview" if (document.referrer.startsWith("https://ne
| ws.ycombinator.com")) { document.location = "https:
| //upload.wikimedia.org/wikipedia/commons/d/d4/Human_fart.wav"
| }
|
| > https://www.boringcactus.com/assets/site.js
| elmt35 wrote:
| 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.
| stefanka wrote:
| 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
| adastra22 wrote:
| 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.
| IshKebab wrote:
| 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.
| bayesnet wrote:
| 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.
| the__alchemist wrote:
| I'm glad they contributed something fantastic to the Rust
| GUI system, but I don't think this is fair: EGUI is
| fantastic.
| adastra22 wrote:
| 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.
| the__alchemist wrote:
| 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.
| norman784 wrote:
| 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
| cultofmetatron wrote:
| they recently opensourced https://www.gpui.rs/ which is
| basicly the ui code pulled into its own framework
| weinzierl wrote:
| 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.
| Jaxan wrote:
| > 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.
| dale_glass wrote:
| 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.
| miki123211 wrote:
| 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.
| kibwen wrote:
| 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/599108c87
| 7da33bc03cb73da...
| eviks wrote:
| 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
| tomrod wrote:
| 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.
| acdha wrote:
| 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.
| deafpolygon wrote:
| 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.
| Narishma wrote:
| There has to be a reason when 99% of GUI apps don't
| support it.
| deafpolygon wrote:
| 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.
| Tepix wrote:
| " _Maybe one day an AI bro who pays for Twitter will contribute
| something positive to society, but this is not that day._ "
|
| Haha!
| linhns wrote:
| Given Qt consists of hardcore lovers of old C++, this is
| unlikely to happen in this generation.
| Kelteseth wrote:
| They literally announced that they are working on it:
| https://www.qt.io/qt-bridges
| andrewl-hn wrote:
| 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.
| kibwen wrote:
| 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.
| hombre_fatal wrote:
| 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.
| jnovek wrote:
| 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.
| WD-42 wrote:
| 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?
| jvanderbot wrote:
| And built in remote use via SSH.
| c-hendricks wrote:
| 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.
| eviks wrote:
| 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!
| hombre_fatal wrote:
| 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.
| prmoustache wrote:
| Maybe in theory, but in practice they literally all fail
| at that.
| orbital-decay wrote:
| 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.
| OkayPhysicist wrote:
| 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.
| ndiddy wrote:
| 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.
| hombre_fatal wrote:
| 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.
| berkes wrote:
| 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.
| speed_spread wrote:
| 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.
| PoorRustDev wrote:
| "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."
| IshKebab wrote:
| 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.
| the__alchemist wrote:
| 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.
| the__alchemist wrote:
| 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.
| claudiug wrote:
| there is this new library: https://longbridge.github.io/gpui-
| component/
| athoneycutt wrote:
| What about Iced or libcosmic (based on Iced)?
| WD-42 wrote:
| 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.
| the__alchemist wrote:
| 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!
| dlivingston wrote:
| 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.
| k_bx wrote:
| Why not just use Arc and clone the cyclical references as
| much as you want `button: RefCell<Option<Arc<Button>>>`?
| vablings wrote:
| 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
| krzyk wrote:
| > 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.
| junon wrote:
| > 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.
| renewiltord wrote:
| Oh good collection. This is good. Found lots of good tools here.
| discoinverno wrote:
| Shameless plug of my TUI game, also built with Ratatui
|
| https://github.com/ricott1/rebels-in-the-sky
| benrutter wrote:
| > P2P terminal game about spacepirates playing basketball
| across the galaxy
|
| Absolutely fantastic description right there.
| seabass wrote:
| 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.
| gausswho wrote:
| 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.
| discoinverno wrote:
| Ja, I know, it's a coin flip, sometimes it works :( I added a
| youtube link just below it, it's the demo
| nhatcher wrote:
| (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.
| jossephus01 wrote:
| Nice. It would be also cool if they add 'cargo install %tool%'
| commands for each one.
| submeta wrote:
| 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
| timeon wrote:
| fzf is Go. There is Skim, which is done in Rust.
| eric-burel wrote:
| 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.
| whycombinetor wrote:
| Don't all the major coding agents have CLI mode now? Cline CLI.
| Opencode CLI. Codex CLI. Gemini CLI. Claude Code CLI. Etc.
| pjmlp wrote:
| 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.
| nobleach wrote:
| 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.
| palata wrote:
| 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.
| nhatcher wrote:
| Hmm, that sounds bad. Were you running the debug build? Like
| just running 'cargo run'?
| palata wrote:
| 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.
| nhatcher wrote:
| Thanks! I will definitely have a look at this. I really
| want to like Ratatui but I do wonder how much bloat there
| is
| nhatcher wrote:
| Related from yesterday:
|
| Bluetui - A TUI for managing Bluetooth on Linux
|
| https://news.ycombinator.com/item?id=45817114
| https://github.com/pythops/bluetui
| vinhnx wrote:
| 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
| thomasfl wrote:
| 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.
| diab0lic wrote:
| 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.
| zdragnar wrote:
| I use gitui on Windows and it is amazing, though mostly from a
| git bash shell.
| diab0lic wrote:
| I'd definitely use something like this too, but don't have
| the luxury of telling my end users to.
|
| They're very nontechnical.
| the_gipsy wrote:
| 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.
| unmotivated-hmn wrote:
| This is very cool, thanks for sharing! p.s. I don't think
| Ghostty implements this protocol (yet?)
| the_gipsy wrote:
| You're right, I think I (mis)heard it on 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!
| Derpdiherp wrote:
| 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.
| swiftcoder wrote:
| There are some truly gorgeous TUIs in that list
| Thom2503 wrote:
| 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...
| whycombinetor wrote:
| 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..."
| alfiedotwtf wrote:
| 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?
___________________________________________________________________
(page generated 2025-11-06 23:01 UTC)