Why we use Tailwind at Kit
When my coworker first introduced me to Tailwind (hi Mark), I had the same reaction as most people that hadn’t used a utility-first CSS framework before. Why do we need this? If we’re writing solid CSS everywhere… and all following the same patterns, conventions, and rules… and keeping our UI consistent across different teams, then we don’t need a framework that pollutes our HTML with all these non-semantic class names.
Then I took another look at our CSS…
We used bootstrap, BEM, OOCSS, some css modules, and many other patterns and conventions across the application. No one really knew which one was the right one to use at any given time. No one knows what is used and unused. Our CSS had become an append-only stylesheet.
So we decided to give Tailwind a shot and styling our application immediately became easier for everyone. We no longer need to think about what conventions we’re following, what to name things, or where to put styles. We don’t have to worry about breaking styles somewhere else in the application or our stylesheets continuing to grow unchecked. We only need to follow a few simple rules:
- Use our component library
- Use Tailwind
- Fallback to inline styles
- And that’s it.
There are many articles about why you should use Tailwind, but why do we use Tailwind? Because it simplifies just about everything when it comes to styling UI across our teams. It eliminates decisions of where to put things or how to write them. It comes with great documentation. For teams, especially with varying backgrounds and UI skill levels, Tailwind is a massive productivity boost.