The case for boring components
The most impactful components I've ever built were the ones nobody noticed. That's the point.
There’s a certain kind of developer who gets excited about a new component. They’ve thought about the API, the variants, the edge cases. They’ve seen some clever pattern on a conference talk and they’re going to do that here.
I used to be that developer. I’m not anymore.
The most useful components are invisible
The best Button component I ever shipped was the one nobody talked about. It handled focus states correctly. It communicated disabled state accessibly. It worked in every context we threw at it. It was boring as hell and it was exactly right.
Nobody sent a Slack message saying “great Button”. Nobody mentioned it in a retro. It just worked, and working quietly is the highest praise a component can receive.
The components that generate excitement are usually the wrong kind of components. They’re interesting to build, complex to maintain, and almost always trying to solve a problem the product doesn’t actually have yet.
Complexity has a carrying cost
Every clever abstraction in your component library is a thing that someone has to understand, debug, and eventually refactor. The cost isn’t just at creation time — it compounds. A complex component that saves two engineers thirty minutes each in the short term can easily cost ten engineers thirty minutes each over a year of maintenance.
The question is never “is this clever?” The question is “will the next engineer who touches this understand immediately what it does and why?”
What boring actually means
Boring doesn’t mean bad. It means:
- Clear, predictable API with sensible defaults
- No logic that isn’t strictly necessary
- Accessible out of the box, not as an afterthought
- Composable rather than configurable-to-death
A boring component is usually the result of a lot of work. You have to resist the urge to solve future problems. You have to make decisions that feel too simple. You have to trust that “good enough” is actually good.
Closing thoughts
Build boring components. Your future self, your team, and the people using your product with assistive technology will thank you. The interesting part isn’t the component itself — it’s what it makes possible.