Tailwind or not

I am going to rebrand my business. Therefore, there has to be a new website, and I wonder if I should use Tailwind CSS this time.

To give a bit of context, I used Tailwind last year with great success for epicenter.academy, whose code I've to touch every few months.

In addition, I've invested some time learning how to write more maintainable CSS a few years back when I rewrote the CSS of a site. Back then, I ended up using inuitcss, which is the reference implementation of Harry Robert's ITCSS architecture.

Unfortunately, there's not much activity in the repo anymore. If there would, I would probably not hesitate to use it again.

Pros and cons

Throughout last year's project, I kept some personal notes on the practical usage of Tailwind. Here they are with a little bit of explanation.

Pros

1. Documentation is fantastic and on par with, if not better than, the Rails docs.

2. UX of documentation is great too. You can find things quickly with Ctrl+K.

3. It's very mature. It comes with many features one needs during a project, e.g., the safelist feature.

4. It's backed by a company I trust, which is enough reason to believe it will be maintained for the next years.

5. Its API is consistent. E.g., one can easily guess utility class names.

6. Responsive design capabilities are a joy to use.

7. Speed of initial development is great.

8. Tailwind removes unused classes from the final stylesheet.

9. Tailwind Playground is a convenient tool to test things out.

Overall it's one of the best and most thought-out tools I've ever used. It's a joy to work with.

However, I've also noticed some things I regard as disadvantages or at least problems for which I've yet to find a solution.

Cons

1. You sort of unlearn writing plain CSS. Tailwind is a wrapper library around CSS that hides the real properties and values. It makes it quite easy to use stuff you're not yet familiar with. In my case, it was CSS grid.

The downside is that your ability to write plain CSS diminishes. This makes you less fit when debugging your site and less fit when looking at other websites' CSS.

2. Hard to document. CSS needs more documentation than other languages because it's not very expressive. But having all style information in HTML makes documentation harder.

Sure, you can put your comments in HTML or template engine comments. However, having all classes in one line makes connecting the comments to the corresponding Tailwind classes harder.

Yes, nobody forces you to write all your classes in one line. But splitting the class list into multiple lines would make the HTML markup more unreadable.

CSS has oddities, and I don't know a decent way to document these when writing utility-first CSS.

3. Hard to comprehend. During a component's initial development (i.e., the code-writing phase), we have a detailed model in our minds of the involved elements and classes. However, in the project mentioned above, despite doing my best to extract components into template fragments, I find it hard to build up the mental model of a component again when revisiting it.

I often find myself asking what a particular HTML element with a bunch of Tailwind classes is supposed to be. Is it the card's title or the sub-title? Or is it something like a tagline? Which parts does the card even contain? Neither the element's type nor the classes are very telling. With something like BEM, each part within a component gets a name that entails what it is.

And yes, you can have the same with Tailwind. Simply declare your BEM-like classes in a CSS file and use Tailwind's @apply. But Tailwind makes a strong point against it.

One could split up a component's template partial into smaller ones to overcome the issue. However, this erodes one of Tailwind's selling points: to think less about names.

4. Incompleteness of library. While I mentioned that the API is very mature and entails everything you need most of the time, sometimes it does not. In last year's project, Tailwind didn't include one property I needed. That's a disadvantage of wrapper libraries. Compared to the other three downsides, I consider it marginal. It would not make me doubt using Tailwind again.

Conclusion

Speaking of using Tailwind again, should I?

I conclude that I'll not use it for the project in question.

These are my two reasons:

1. I don't want to unlearn CSS any further. Towards the end of developing epicenter.academy, I felt disconnected from "real" CSS. I was using CSS grid for the first time with the help of Tailwind, but I haven't had a clue what was going on under the hood. I want to keep my CSS skills.

2. When I return to the codebase now and then, I want this to be a joy. As described above, I want to avoid guessing the intent of a particular piece of code. I accept that I'll have to come up with good names and that writing the initial code will take longer. Naming is hard, I know. But in my experience, good names are worth it.

Will I use Tailwind again for something else?

Probably yes. As mentioned in the concluding paragraphs of Tailwind's pros, it is one of the best tools I've ever worked with. I'll always consider it an option for future projects.

I think Tailwind is especially suited for design-heavy websites, e.g., landing pages, that change often.