Why We Use Tailwind at ConvertKit

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.

Why do you use/not use Tailwind?

P.S. We're hiring a few full stack engineers at ConvertKit. Learn more here convertk.it/engineer

Comments

[Sung M. Kim]

I started learning/using Tailwind recently.

The reason I was interested in was it was low-level enough to apply styles I wanted and easy to extend.

The documentation was great as well.

Moreover, you can create a minimal viable product/site fast :)

Lastly, it's not frontend library/framework (React/Vue/Svelte) dependent.

[Brendan Carney]

Agreed! I've been able to build out things that look good much, much faster since we started using it. And I love that I don't have to name things all the time too.

[Brendan Carney]

Like the other commenters mentioned, the component is our unit of reusability. Spacing is something we're still figuring out, but it would be a similar problem without Tailwind. Recently, I've been getting inspiration from Mark Dalgleish, and experimenting with different layout components, like Stack. So we have something like this:

<Stack spacing={2}>
  <Heading/>
  <Content/>
</Stack>

And the elements inside will all have the correct spacing applied. That's probably a topic for a post on its own though.

[Jamie Barton]

How do you make things reusable? Let's say a card component.

This comes up in discussions time and time again. It's funny because we've spent so long discussing the best ways to abstract our JS, that we feel we still need to do it with Tailwind, but in actual fact, if your component is isolated, then those styles live along with it.

[Zeb Pykosz]

If it's the same component, it should be in a singular component filed that's shared.

Otherwise the difference in spacing is fine since it still all ties back to the theme defined spacing.