React Bits: The Art of Standout UI

Hey everyone, I'm David. I'm the creator of React Bits, an open source library that I started last year. In this talk, I'll share what building React Bits taught me about designing UI components that stand out, stay reusable, and leave an impression.

In just a year, React Bits has grown into a collection of over 130 components and it's now getting close to 40,000 GitHub stars, which has been amazing, surprising, and honestly, sometimes a little scary. Because once that many people start using your components, you quickly learn the difference between something that looks good in a demo and something that actually survives in real projects. And that difference is what I want to talk about today.

Most modern UI works pretty well. It's responsive, it's clean, it probably has nice spacing, good typography, rounded cards, and call to action buttons that say something like get started. And that's great. I'm not here to argue against clean UI. Clean UI is good. It pays the rent and everyone likes it. But the web has reached a point where a lot of interfaces are starting to feel very similar.

Same layout patterns, same gradients, same hero sections, same feature cards, same little icons, and rounded squares. And none of that is bad by itself. These patterns exist because they work. But when everyone uses the same pattern in the same way, it becomes harder for a product, a portfolio, or a brand to feel memorable. So the question becomes, how do you create moments that feel distinct without making the interface noisy?

How do you make something stand out without making it scream? And this is the space ReactVids is trying to explore. When I say standout UI, I do not mean adding effects everywhere. I do not mean that every button needs particles. I don't mean that every container needs a shader. And I definitely don't mean that your pricing page should feel like you're entering a boss fight. What I mean is more intentional than that. A standout interface has moments that people remember. Maybe it's a background that gives the page atmosphere. Maybe it's a card that feels alive when you hover it.

Or maybe it's just a little text animation that gives your headline rhythm. And in this case, for what you see on this slide, is this little ASCII animation that really stands out on the right. These moments create identity, and identity is what people remember. So the idea behind ReactVids is not just to make animated components. The idea is to create reusable visual moments that developers can take, customize, and make their own.

ReactVids actually started from a very simple observation. There are so many amazing front-end experiments online. There's shader demos, there's hover effects, there's animated backgrounds, creative cards, text animations, little interactions that make you stop scrolling for just a second. But a lot of them are not easy to use in an actual React project. They might be buried inside of a code pen, they might be written as a one-off experiment, or they might have hard-coded values everywhere. They might look beautiful in one very specific setup, but become painful the moment you try to use them in a real layout.

ReactVids became my attempt to take that kind of creative front-end work and turn it into something more usable. The goal is to make standout UI more accessible not by removing the craft but by packaging the craft in a way that's easier to use. At the beginning, ReactVids was not a grand master plan. It was mostly me building components I wished existed. I wanted components that felt polished, expressive, and fun to use most of all. And I wanted them to be practical enough that someone could actually drop them into a project.

And as the project grew, the community started shaping it. People would use components in ways that I did not expect. They would ask for more customization, they would ask for TypeScript versions, they would ask for Tailwind, they would ask if a component could be made more subtle, more intense, more responsive, more flexible. And over time, that changed how I thought about the library.

At first I was mostly asking, can I make this look great? But the better question became, can I make this useful to many different people in many different contexts? That's a much harder question, and it leads to much better components. When I think about memorable UI, I usually come back to three main qualities. The first is motion. Motion gives an interface rhythm. It can guide attention, it can create anticipation, and it can make the page feel less static and more alive.

The second one is depth. Most screens are flat by default. Depth gives interfaces atmosphere. That can come from shadows, gradients, noise, particles, lighting, blur, or shaders. And that makes a screen feel less like a flat arrangement of boxes, and more like a space. And the third is interaction. The best interfaces often feel like they notice you. They respond to your cursor, your scroll, your focus, and your input. And that response creates a small relationship between the user and the interface.

And those three things, motion, depth, and interaction, are a big part of React Bits. But the important thing is that none of them should be used blindly. They need to serve the experience, right? And that brings us to the hard part. The hard part is balance. If an interface is too plain, it may work, but it might not leave an impression. If it's too expressive, it can become distracting. So the sweet spot is somewhere in the middle.

Expressive, but controlled. Distinct, but still useful. Memorable, but definitely not annoying. A standout component should have a reason to exist. It should support a section, it should frame content, it should create atmosphere, and it should make an interaction feel better. It should help communicate something about the product or brand. This is why I think of standout UI less as decoration and more as composition. You are deciding where the interface needs energy, where it needs calm, and where it needs something that people will remember.

So let's make this concrete with one component. Magic Rings. Magic Rings is a shader-based visual component built around animated rings, glow, motion, color, blending, hover behavior, mouse influence, subtle parallax, and texture. But the reason I chose this component for the talk is not because it looks cool. It's because Magic Rings shows the full process behind many React-based components. It starts with a visual idea, then it becomes a shader, then it becomes a React component, then it becomes a customizable API. Then it becomes something people can use in very different contexts. A landing page, a card, a footer, an about section.

And the interesting part is not just the final visual. The interesting part is how you turn that visual into something reusable. And this is where the component gets interesting. In a hero section, Magic Rings can be the main visual anchor. It can sit behind the headline and make the page feel more atmospheric. In a card, it has a different job. It needs to be smaller, more contained, maybe less intense. It becomes a detail, not a whole scene. In a footer, it might need to be even more subtle, a soft visual layer that gives the bottom of the page some life without competing with links or calls to action.

And in an about section, it can work more editorially. It can suggest energy, motion, or focus. Same component, different scale, different intensity, and a different role. And that's the real challenge. The component cannot just be one fixed effect. It needs to be a flexible visual system. For components like this, I usually do not start with code. I start with a feeling. For Magic Rings, the feeling was something like orbital, focused, energetic, a little futuristic, but not so much so that it only works on black backgrounds. I wanted it to feel like something you could place inside a real interface. Something that could be expressive but still controlled.

And the early references were things like radial lights, thin rings, soft glow, and subtle distortion. And then the question becomes, what's the reusable idea here? Because making a cool ring animation is not enough. The reusable idea is more specific. It is layered, animated rings that can adapt to different moods, different sizes, different sections, and different levels of intensity. Once that's clear, the technical decisions become easier. The first approach was the obvious one. Can this just be CSS? And sometimes the answer is yes. CSS is still wildly powerful. You can create rings with borders, gradients, pseudo elements, masks, transforms, opacity blur, and keyframe animations. For a lot of components, this is definitely the right choice.

CSS is always easier to understand, it's easier to modify, easier to ship, and has way less setup. But for magic rings, CSS alone started to feel too rigid. The movement feels a bit too mechanical, the glow is harder to control, and the rings felt more like stacked elements rather than a single living thing. And I wanted the components to support things like radial falloff, procedural noise, things like that.

And that's where shaders become super useful. Because with a shader you're not just animating dominoes, you are actually generating the pixels. This means you can control light, falloff, distortion, blending, transparency, and motion in a much richer way. So the decision was not shaders are cooler, the decision was this specific visual idea needs the kind of control that a shader offers. Now if we get into the shader mental model, at a simple level the magic rings shader is just asking a question for every pixel.

What happens if we rotate the coordinate space? And what happens if we offset it slightly based on the mouse? Should the visual scale on hover? How quickly should it fade? What color should it use? How much noise should we add? That's the basic mental model. And instead of thinking in terms like divs and spans, you start thinking in terms of space, distance, light, and time. The rings themselves are not dom elements, they are mathematical regions. And the glow is not a box shadow, it's calculated based on distance, right?

The motion is not just a CSS keyframe, it's time flowing through the shader. And this is what gives magic rings the feeling that I wanted, because it feels less like a rotating asset and more like a generated visual system. This is the core ring function for magic rings. I would not put the entire shader code on a slide, because that is a quick way to lose a room. But this function shows the heart of it. First, each ring gets its own time offset. This is what keeps the rings from moving as one flat layer. Then we calculate the current radius, which grows over time using the U-scale rate uniform.

Then we calculate the distance between the pixel and the ring. That distance becomes the base for the ring intensity. There's also an angular value based on a tan, which helps shape the ring differently depending on the pixel's angle. And that gives the rings a little more character instead of making them perfectly uniform circles. So even though the result feels visual and organic, the underlying logic is still very controlled. It's a set of small decisions about distance, timing, falloff, and shape.

Now let's talk about the shader uniforms. This is where the shader starts to become a component, because these uniforms are the bridge between react and the visual effect. A uniform is a value we pass into the shader from the outside, right? And this is important because the visual should not be hardcoded. Time controls the motion. Attenuation controls how quickly the rings fade. Line thickness controls how thick or sharp they feel. Base radius and radius step control how rings are placed. And scale rate controls how they expand. Opacity controls how strong the component appears. And noise gives the visual a little texture.

So these uniforms are not just technical details. They are raw materials for the public API. And now we can move on to the react component, which has a very different job from the shader. The shader creates the visual, but the react component makes it usable. So Magic Rings uses 3js to set up a WebGL render. It creates a simple scene. It uses an orthographic camera, and it renders a plane with a custom shader material. That plane fills up the component area, and then the fragment shader decides what each pixel should look like. The component also handles resize. It uses the container dimensions and device pixel ratio to update the renderer and the shader resolution. It also tracks the mouse and makes it smoother. It tracks hover scale. It tracks click effects, and passes all of those values into shader uniforms on every animation frame. And then at the end, it cleans everything up when the component unmounts.

And this is where a creative component becomes a responsible component, because the visual effect gets all the attention, but the lifecycle code itself is what makes it safe to use in someone's app. Now we get to the public API final. And this is where the component becomes a product. And yes, this is a lot of props, I know. But for this component, that is intentional, trust me. The props are actually grouped around real creative controls, because Color and Color2 control the palette, Speed, Fade In, Fade Out, and Scale Rate control timing, Ring Count, Base Radius, Radius Step, Line Thickness, Ring Gap, and Attenuation control the ring system. And Opacity, Blur, and Noise control the final texture and presence. Rotation changes the composition. And we also have interaction props like Follow Mouse, Mouse Influence, Hover Scale, Parallax, and also a Click Burst control interaction.

So while the API is large, it's definitely not random. It maps the kinds of decisions that someone actually needs to make when placing this component in a real interface. Do I want it subtle? Do I want more rings? Do I want mouse movement? Do I want it to feel more like a hero visual or more like a background accent? And that's the whole point of the API. And since we're talking about props, there's a common idea in component design that too many props are bad. And a lot of the time, that's definitely true. A component with too many props can become hard to understand. It can become a control panel instead of a clean API. It can feel just unfocused.

And for a normal bot, 40 props probably means that something has gone wrong. But creative components are a little different. When the value of the component is expression, customization is not just a nice feature. It's actually part of the product. Magic Rings needs to work in a hero, a car, a footer. And these contexts have different needs, different sizes, different colors. So in this case, more props can be worth it. And the question is not simply, how do we expose fewer props? The better question is, which props create meaningful control? Because if a prop helps someone adapt the component to a real use case, that prop might be worth having. And the way I think about this is that it's important to know the difference between meaningful control and noisy control. Meaningful props map to the way someone thinks about the component. For example, the ones on the left here are meaningful controls. Noisy props are different. They expose implementation details without giving much creative value.

They use names that only make sense if you wrote the shader. They give people the ability to break the component without helping them adapt it. So the goal is not to expose everything, but rather to expose the right things. And that's the design work behind a reusable creative component. You are deciding which controls should become part of the public API and which details should stay internal.

And there's also a newer reason that props really matter. AI-assisted development. A lot of people now use AI agents to install components, modify them, and adapt them to a project. And sure, an AI agent can go directly into the code. It can edit the shader. It can change the internal values. It can move things around. But that is not always the best workflow because it can introduce subtle bugs and it often makes the component harder to maintain later.

If useful props are already wired, tested, documented, and working, then both humans and AI agents can make safe changes faster. And instead of asking an agent to surgically edit shader math, you can say make this slower, make it blue, make it less intense. And the agent can map that request to props that already exist. And that ultimately saves tokens, it saves headaches, and it keeps customization inside the intended API. So props are not just settings, they're safe handles for developers, for designers, and increasingly for AI agents.

And this connects to the bigger philosophy behind React Bits. The library is built around three things. Adoption, ownership, and expression. Adoption means it should be easy to try. The component should not feel like a huge commitment. Ownership means that people should feel comfortable taking the code and making it theirs. And expression means that the component should help them create something distinct. Something that doesn't look like every other website. Something that gives the interface a little more identity. And that's the reason customization matters so much because the point is not just to give people beautiful defaults, the point is to give them a strong starting point and enough control to make it fit their own work.

So if I had to summarize the magic rings process, it would be like this. Start with the feeling. Before code, before props, before implementation, understand what the component should make the interface feel like. Then build a visual system. Not just one static result, but a system that can adapt. Then wrap the complexity in a clear API. The shader can be complex, the 3GS setup can be complex, and so can the interaction logic. But the surface area should feel understandable. Then customize for real contexts, hero, card, footer, about section, product section. Those contexts should influence the props. And finally, ship for adoption. This means good docs, good defaults, multiple versions, and clean structure. Your code needs to be code that people can actually bring into their projects.

The bigger lesson from ReactVids is that components do much more than work. They help a project feel more alive, more expressive, and more memorable. And that is especially powerful in open source because you're not just shipping a finished visual, you're shipping a piece of creative infrastructure. Something that people can build on. And I personally think that the web is better when it has more personality. Not every interface needs to be loud.

Not every interface needs to be loud. Not every product needs shaders everywhere. Not every section needs to animate. But every product has moments where it can feel more distinct, more intentional, more memorable.

And that is what ReactVids is all really about. Creative components that do more than work. Components that help people create interfaces with identity that can be copied, customized, adapted, and made your own.

Because standout UI is not just about doing more. It's about creating moments that people remember. And if you want to try it for yourself, I invite you to go to reactvids.dev and see what it's all about. I hope you enjoyed this talk. Take care, and I'll see you later.