ratatui-themes: Building a Theme Library and Finding a Community

There’s a moment in every side project where you push your code to the world and think, “Well, that’s done.” You close the laptop, maybe feel a brief spark of accomplishment, and move on. Nobody’s going to notice. It’s just another crate in a sea of crates.

And then someone opens an issue.

The Backstory

While building Perch, Feedo, and Hazelnut, I kept running into the same problem: theming. Every ratatui application handles colors differently. Some hardcode hex values. Others define their own theme structs. There’s no shared vocabulary for “give me a Dracula theme” or “switch to Catppuccin.”

I wanted a simple, reusable library. Define a theme by name, get consistent semantic colors—foreground, background, accent, error, warning, success—that any ratatui app could use. No runtime overhead. No complex configuration. Just Theme::new(ThemeName::Dracula) and you’re done.

So I built ratatui-themes.

What It Does

The crate is deliberately minimal. It gives you:

• 15+ popular themes — Dracula, Nord, Catppuccin (all four flavors), Gruvbox, Tokyo Night, Solarized, One Dark, Kanagawa, Everforest, Rosé Pine, and a few originals
• Semantic colors — Every theme maps to the same set of named colors, so your app looks consistent regardless of which theme the user picks
• Theme cycling — Built-in next() and prev() methods, because every TUI app needs a “press T to switch theme” feature
• Light/dark detection — Programmatically check if a theme is light or dark, useful for adapting UI elements
• Optional serde support — For persisting the user’s theme choice in a config file

Zero dependencies beyond ratatui itself. The whole thing compiles in seconds.

Publishing to crates.io

Publishing a crate is oddly nerve-wracking every time. You run cargo publish, watch the progress bar, and suddenly your code is on crates.io for anyone to install. There’s no review process, no gatekeeper. Just you and the Rust ecosystem’s trust model.

I wrote thorough documentation—rustdoc with examples for every public function, a detailed README, a changelog. Partly because good docs matter. Partly because if someone was actually going to use this, I didn’t want them to have to read my source code to figure out how.

Then I waited. Not expectantly—I genuinely assumed the crate would sit there with maybe a handful of downloads from bots and search indexers.

The First Issue

A few days later, I got a GitHub notification. Someone had opened an issue. My first reaction was a small adrenaline spike—the kind you get when your phone rings unexpectedly. Is it a bug report? Did I break something?

It wasn’t a bug. It was a feature request. And not just any feature request—a thoughtful, well-structured proposal for “associated colors.” The idea was to add extended color palettes (reds, greens, blues, etc.) that go beyond the core semantic colors, useful for things like charts, graphs, and data visualization.

The message opened with: “I was just looking for something like this three days ago when you published it. Amazing timing!”

I read that line three times. Someone had been looking for exactly what I built. The timing was coincidental, but the validation was real. This wasn’t a theoretical exercise anymore—someone had a concrete use case, and my crate was close enough to what they needed that they wanted to help shape it.

The First Pull Request

Then came the pull request. They’d built a theme gallery example—a visual picker that renders all available themes side by side so you can see what they look like before choosing one. 192 lines of additions, cleanly written, with a new ThemePicker widget.

I reviewed the code, left some comments, we discussed the approach, and I merged it. The whole interaction was respectful, constructive, and genuinely fun. This is open source at its best—a stranger on the internet saw something they liked, made it better, and shared the improvement with everyone.

Why This Matters

I’ve contributed to open source projects before. I’ve opened PRs, filed issues, and reviewed code on other people’s repos. But being on the receiving end is a completely different experience.

When someone uses your library, they’re trusting your decisions. Your API design, your color choices, your documentation. When they open an issue, they’re investing their time to make your project better. When they submit a PR, they’re saying “I believe in this enough to write code for it.”

That’s a powerful thing. And it’s easy to take for granted if you’ve been in the open source world for a while. But with ratatui-themes, it hit differently.

What I Learned

If you’re sitting on a library or tool that you built for yourself, consider publishing it. Here’s what I learned:

• Someone needs what you built. You wrote it to solve your problem. Chances are, someone else has the same problem. The timing might just line up.

• Documentation is your first impression. Good docs with real examples lower the barrier to adoption. People will judge your crate by its README before they ever read a line of source code.

• Start small. ratatui-themes does one thing. It doesn’t try to be a full UI framework or a design system. Focused libraries are easier to maintain and easier for others to adopt.

• Be responsive. When that first issue comes in, engage with it. The early contributors are the ones who’ll shape your project’s direction. Treat their input with respect.

• It doesn’t have to be perfect. Version 0.1.0 had rough edges. That’s fine. Ship it, iterate, improve. The crate is on 0.2.0 now, and each version is better because of real-world feedback.

What’s Next

The “associated colors” proposal from that first issue is still being discussed. We’re figuring out the right API—I suggested a HashMap<String, Vec<Color>> approach instead of fixed fields, which would be more flexible and future-proof.

The crate is integrated into Feedo, Perch, and my other TUI apps. It’s doing exactly what I built it to do: making theming consistent and easy across projects. But now it’s also doing something I didn’t plan for—connecting me with other developers who care about making terminal apps look beautiful.

And honestly? That’s better than any download count.

Check it out: crates.io/crates/ratatui-themes | GitHub | Docs

PRs and new theme suggestions are always welcome. 🎨