What Makes a UI Library Rad? Why we built Rad UI
Maintainer at Rad UI
A look under the hood of Rad UI—why it exists, what makes it different, and how it helps you build fast, accessible, and tastefully designed React apps.
There are way too many UI libraries out there.
And most of them? They’re either too rigid, too bloated, or too… meh.
So why did we build Rad UI? Especially when there are so many other great UI libraries out there like Radix UI.
Because we needed a system that helped us and our team move fast, design with intent, and ship real features without drowning in CSS overrides or ARIA role-checking hell. A system that felt headless, but still came with opinions where it mattered. One that respected accessibility and composability without treating either like an afterthought.
Let me walk you through what makes a UI library truly rad, and why we believe Rad UI deserves the name.
1. Headless Where It Counts, Opinionated Where It Helps
You know the drill: some UI libraries give you components with built-in styles and logic welded together like a mid-2000s Flash game. Want to swap out a color? Good luck battling !important declarations and scoped class spaghetti.
Others swing hard in the opposite direction — fully headless, totally unstyled, dumping a bag of props in your lap with a “you figure it out” shrug. Congrats, you now maintain your own dropdown ARIA roles in six different places.
Rad UI takes the middle path. A path paved with just enough guidance to move quickly, but flexible enough to never box you in.
Here’s what that looks like:
- Components are unstyled by default. Your styles, your system. No fighting someone else’s tokens or design language.
- They’re also accessible out of the box, with ARIA roles, keyboard handling, focus traps, and live regions handled for you.
- APIs are predictable and composable — props are minimal, and common states like
open,disabled, orselectedare exposed throughdata-*attributes. - These state attributes aren’t arbitrary. They're the glue between logic and styling — so you can write expressive CSS or Tailwind that just works.
This lets you build UIs that are:
- Design-system-friendly — plug them into your own component kit with zero drama.
- Composable — nest things, wire up context, do weird edge-case layouts without breaking stuff.
- Framework-respectful — no shadow DOM trickery or magic globals.
In other words: we give you the bones, nerves, and joints — you bring the skin.
You don’t need to reinvent focus logic or ARIA patterns, but you still get total freedom to design how it looks and feels. That’s the sweet spot — and the one most libraries miss.
2. Game Dev Discipline, Applied to UI
I’ve spent a decade building games — where feel is everything. You don’t get away with a janky hitbox or a 200ms input delay. Players notice. Fast.
That mindset helped me shape Rad UI.
- Every component supports keyboard navigation and focus management out of the box.
- Animations are totally under your control and never block interactions.
- State transitions are modeled with data attributes, not flaky class toggles.
It’s UI that feels as responsive as a fighting game input buffer.
3. Tailwind-First, but Not Tailwind-Only
Rad UI is built for Tailwind CSS.
Not in the "we added some utility classes and called it a day" kind of way — I mean the entire architecture leans into data-driven styling.
Because writing bg-white or opacity-0 is only fun when you can target component states predictably. And you can only do that cleanly if your components actually expose state.
<Button data-state="open" className="data-[state=open]:bg-blue-600">
Open
</Button>
Simple. Expressive. No wrapper libraries. No styled-components boilerplate. Just HTML attributes and your styling tool of choice.
Tailwind makes this feel effortless — and we lean into that. Components emit clear state through attributes like data-state, data-disabled, data-orientation, etc., so you can use Tailwind’s powerful selector syntax to style them.
But Tailwind isn’t a requirement. Prefer vanilla CSS? CSS Modules? PostCSS? Totally fine. Rad UI doesn’t care how you style — we just make it easier to style well.
This approach gives you:
- Full control over the visual layer without relying on complex theming APIs
- A clean separation between behavior and appearance
- A way to actually enjoy styling again, especially when building or maintaining a design system
Think of it like this: Rad UI gives your components the right signals, so you can build the visual language you want — fast.
4. Accessibility as a Feature, Not a Checkbox
We don’t ship components that “technically pass a screen reader audit” but fail in the real world. That’s like saying your game runs at 60fps… if you don’t count physics.
Accessibility is an integral part of Rad UI. It’s not an afterthought, a box to check, or a “nice-to-have” feature. It’s baked into the foundation, because accessible UIs aren’t just nice to have — they’re essential for everyone. If your app isn’t accessible, you're leaving out a significant portion of potential users.
Here’s how we make sure Rad UI is genuinely accessible:
- Focus order management is automatic. If you have focusable components, Rad UI ensures they’re in the correct tab order, and properly managed when users interact with them.
- Screen reader landmarks are respected. Whether you’re building a modal, a dropdown, or a complex menu, Rad UI ensures that screen readers can easily interpret your app’s structure and guide users as they navigate.
- Keyboard traps are avoided. No more unexpected behaviors when keyboard users try to navigate away from a modal or dropdown. We ensure that keyboard focus is properly managed, preventing frustrating and confusing interactions.
- Live regions are integrated. Dynamically changing content can be announced by screen readers when necessary, providing a smooth experience for users who rely on assistive technologies.
- Clear state with semantic data attributes: We expose important states like
data-state,data-disabled,aria-checked, and more through clear and predictable attributes. This not only improves styling flexibility but also makes your app’s behavior more understandable to screen readers.
At the core of Rad UI is the belief that accessibility isn’t optional — it’s just good software. We design with the intent of providing the best experience for all users, not just the ones who are able to see and interact with your app in the traditional way.
This isn’t something you need to configure or add on — it’s just part of the system. You don’t have to worry about adding ARIA roles or testing with screen readers. We’ve taken care of that for you, so you can focus on what matters: building great features and experiences for your users.
5. Small Teams, Big Moves
Rad UI isn’t made for giant enterprise teams with full-time design systems squads and a Slack channel dedicated to color tokens. It’s built for you — the indie developer, the startup founder, the small team that wants to ship polished UI without compromising.
Working on a small team (or flying solo) means you wear a lot of hats. You’re not just designing and building — you’re managing time, resources, and expectations. So, Rad UI is built with this reality in mind: it’s lightweight, straightforward, and doesn’t require an army of people to keep it running smoothly.
Here’s how Rad UI helps small teams punch above their weight:
- Fast setup: Whether you’re starting from scratch or plugging it into an existing design system, getting Rad UI up and running takes almost no time. The components are simple, composable, and don’t require endless configuration or setup. Majority of the time will be spent on styling it based on your needs.
- Well-tested: You don’t have to stress about breaking things when you’re moving fast. Rad UI is battle-tested in real-world projects, so you can trust it will perform well across browsers and devices.
- Focus on what matters: You don’t need to maintain complex component libraries or worry about getting the accessibility or state management right. Rad UI does the heavy lifting for you, so you can concentrate on building the unique parts of your app.
- No bloated dependencies: There’s no endless list of packages and dependencies that require constant updates or security patches. Rad UI is designed to be lean and modular, so you only bring in what you need — keeping your bundle size small and your build times fast.
- Design freedom with confidence: Small teams often struggle with balancing custom design with consistency. Rad UI gives you a solid foundation to build on while allowing you the freedom to implement your own design language. Whether you’re going for a highly branded experience or keeping things minimal, Rad UI adapts to your style.
With Rad UI, you get the confidence of a solid, well-tested component set with the freedom to design your way. This means you can ship polished, professional products faster and with less overhead.
Small teams don’t have the luxury of time to fiddle around with UI libraries that are over-engineered or too rigid. Rad UI allows you to build fast, without sacrificing quality — the perfect companion for teams that need to get things done without the extra baggage.
6. Built With Dev Ergonomics in Mind
You don’t need a PhD in ARIA or a full day of context-diving to use Rad UI. We obsess over:
- Autocompletion-friendly props and types.
- Minimal surface area — you don’t need three wrappers and a config provider just to get started.
- Docs that explain the why, not just the how.
In short: it’s designed for humans who just want to get stuff done.
So... Why Call It Rad?
It's a long story. But if we had to summarize our thoughts, "Rad" is more than a nod to the 90s.
It’s a philosophy:
- Responsive (to your needs, inputs, and users)
- Accessible (to everyone, always)
- Designable (by you, without the handcuffs)
And also, yeah — it just sounds cool. Like a skateboarding ninja with great taste in typography.
Try It Out
Rad UI is open-source, lightweight, and constantly improving. If you're building a new product or refreshing your design system, I think you'll like what you find. I could be totally wrong, I'd still like to hear from you.
Got thoughts, questions, or spicy takes? Hit me up on Twitter or open a GitHub issue. I read everything. Especially the constructive rants.