Use 98% TailwindCSS, 2% plain CSS
Tags: css, tailwindcss
Published: 2023-03-22 05:13:58

---
title: Use 98% TailwindCSS, 2% plain CSS
published: true
date: 2023-03-21 16:29:49 UTC
tags: css,tailwindcss
canonical_url: 
---

Yes, it’s awesome. I declared my affection a while ago and it has genuinely altered the way I write frontend code. [Everything I loved about it](https://itnext.io/and-naming-things-tailwind-css-typescript-and-mammals-9eab459633d2), I still love. Additionally, it has nudged me out of the habit of making CSS rules that cascade. While those certainly have their advantages, avoiding them means that you can move html around without any fear which has felt very liberating to me.

![](https://cdn-images-1.medium.com/max/620/0*JQT_DZMvUfpan2eL.jpg)

Software development can be fickle like the fashion industry and right now, utility classes are _on fire_. I suspect that in time, they will fade a bit, the way micro services or NoSQL databases have. We have a tendency as a community to become infatuated with new principles and enter a state of limerence, believing that they are a universal solution that must be applied everywhere, to everything.

So, while I can attest to the many benefits of utility classes, I find that there are a few downsides worth pointing out.

When a designer hands me a Figma file, utility classes are great because I can easily identify the ones that match the margin, padding etc. that I am looking at. It’s a lot easier than scanning through CSS files, looking for the class that matches everything, if a such even exists. _However_, it is also easy to overlook subtle details like letter spacing and line height. Those are things my non-designer eye is more likely to overlook and since there isn’t a rule set once and for all, I need to actively remember them.

The same applies to classes for pseudo-states like hover and disabled. The fact that you always have to specify everything makes this particularly easy to miss as you can quickly look at the result and not notice that anything is missing, unless you explicitly try out those states.

Tailwind recommends extracting components in React or whatever your framework is to encapsulate styles, rather than CSS classes. This generally seems to me to be a sound principle. Nevertheless, there are situations where it can be frustrating to have to split code into atoms, especially if you have a strict one-component-per-file policy (which I don’t recommend, though!)

Finally, there are a number of things that I really just want to set and forget. For instance, I generally want all my links to look the same. Having to add a bunch of classes to each one feels unnecessary and silly, as does creating a component.

Overall, Tailwind is a fantastic framework that I will continue to use. I have just reached the personal conclusion that there is _absolutely_ nothing wrong with creating a .css file or two to complement it (and to be clear, I don’t think the Tailwind people would say otherwise!) You can use [apply](https://tailwindcss.com/docs/reusing-styles#extracting-classes-with-apply) or you can just make plain old styles, it’s all good. Just don’t be dogmatic for the sake of dogma.