Why Are We Still Rebuilding Buttons?
The shape of a button has never changed the value of a business. And yet, most front-end teams will spend the next quarter debating how much radius is too much radius, whether neutral-200 is too warm, and which flavor of the month framework best expresses the same five states every component has always had: default, hover, active, disabled, and loading.
It’s not that design doesn’t matter. It does. Visual coherence builds trust. UX decisions drive engagement. The best products in the world feel effortless, and that’s not an accident. That’s craft. But the problem isn’t the craft. It’s the scaffolding we rebuild every time a new design system lands.
We’ve convinced ourselves that each shift in visual language requires a corresponding shift in tooling. A new framework. A new set of utilities. A new build pipeline just to express a slightly softer elevation model or a more optimistic hue.
We’re chasing polish with power tools.
And in doing so, we’ve turned what should be a solved problem into a perpetual reinvention cycle. We rip out CSS files and replace them with Tailwind configs. We throw away a decade of SCSS mix-ins for design token compilers. We strap JavaScript to every interaction like it’s the only way to express variation. And every time we do, we call it modernization. But what we’re really doing is hiding the fact that we’re still reinventing buttons.
Because underneath the layers of abstraction, most products don’t need new styling logic. They need a theme. Just a theme. A way to represent a set of decisions: color, spacing, motion, radius, and apply them consistently.
And CSS can already do that.
We have :root. We have custom properties. We have color-mix() and oklch() and @media (prefers-color-scheme). We have the ability to change themes with a single class or a data attribute. No build step. No runtime. No dependencies. Just the platform, doing what it was finally designed to do after two decades of waiting.
Recommended by LinkedIn
We don’t need another framework. We need to stop pretending that every aesthetic shift is a technical one.
You want soft shadows this quarter? Define them. You want dark mode? Flip the lightness. You want semantic tokens instead of hardcoded hex values? Use variables. You want dynamic themes per customer or user? Use data-theme. You want all of this to just work without a giant stack? Then stop piling on more stack.
The problem isn't that we lack the tools. The problem is that we've mistaken motion for momentum. We keep swapping out hammers because we don’t want to admit the house is already built.
What’s missing isn’t innovation. It’s restraint.
There should be a theme layer, native and abstracted, that lets designers make visual decisions without writing code, and lets developers apply those decisions without a plugin. A layer where tokens mean something, and tokens are all you need. A system where you don’t have to explain how to get from Figma to production. You just drop in a file and it works.
We should have had this ten years ago. The only reason we don’t is because we’ve been busy chasing novelty. And now that the browser has finally caught up, no one’s noticed that we don’t need to reinvent anything anymore.
We just need to stop chasing the glow of the new and start building on the foundation we keep pretending doesn't exist.
If you're still rewriting buttons, maybe it's time to ask why.
🏄 Experienced MAUI/Xamarin and Microsoft Platform Architect. Available for now... ⌛
1moOver packaging your UI controls into a design system is another kind of bike shedding. Code reuse is good but when you turn your controls into kitchen sink projects instead of using the flexible nature of the design system in.net Maui you're wasting your time on maintenance and changes.
Software Team Lead at Truelook Construction Cameras
1moGood article. As engineers we're always chasing the new shiny thing.
Technical Consultant at ServiceNow
1moAre we not all - in one way or the other - assistants to the king‘s deputy joker‘s personal manager?
Tech Lead At Demis - Full Stack Java: TypeScript: Node Software Engineer, Angular, Spring Boot, React, Enterprise Software, Microfrontend, FOSS Advocator, CI/CD, Web Accessibility, Trainer
1mowell said
Senior Software Engineer | JavaScript, TypeScript, React, Next.js, GraphQL, Node
1moVery well written! 👏 Thanks a lot for sharing! "The problem is that we've mistaken motion for momentum." Words! 🙌