On Tailwind CSS

There is no doubt, Tailwind CSS has taken the web world by storm. Created/spearheaded by Adam Wathan, with the additional help from people like Jonathan Reinink, David Hemphil and Steven Schoger. I remember first reading about it shortly after the 2017 v0.1 release. My initial thoughts were that it looked pretty similar to other css frameworks that had been out like Tachyons, Atomizer and Basscss. With the v2.1 out in 2021 sometime they had a new killer feature up their sleeve, JIT compiler. That made it more interesting over other frameworks and really propelled it into popularity. I think it also allowed it to be easier to use . It had already passed a $2 million business (by way of Tailwind UI components), but it really was sometime around the end of 2021 beginning of 2022 that it started to catch fire.

It was around the summer of 2021 that I joined a project that had just gotten started. They had already started to integrate Tailwind, just because they used a npx create command that had it on automatically. I had messed around with the css framework before, read the docs, etc, but this was my first real world, production usage. That project has been live now for 4 years as of writing this and I’ve worked on it full time for 2 years and part time for the other 2. All that to say, yes, I’ve used Tailwind. I have a lot of experience with it, beyond this very large codebase I also used it in a few side projects. The difference there was I wanted to see if I was in charge of everything from the start, maybe I could fix some issues that I didn’t like with the other projects where I wasn’t able to make final decisions on integration. Alas, no, after many attempts, tailwind wasn’t for me. Let me explain.

My issues with Tailwind

This is where things get controversial, I know. I’ve been around the tech world for a while, I know that Tailwind has become a flame war, ala, tabs/spaces, iPhone/Android, Mac/Windows, Netscape/Internet Explorer, etc, etc. So I know saying anything negative about Tailwind will make some upset and make some happy. But this blog post is more or less just my experience and my issues with it, you may have the same issues or it might work great for you. And just to be clear, I think there are positives too and even specific use cases. But I think there are people who do like it, claim its better than css, but they honestly have no clue that they are just trading one issue for another.

Let’s start with the issue of seperation of concerns blog post that many people reference as the source for ‘seeing the light’ on Tailwind. Lets start with a blockquote from that blog post under the Enforced consistency section:

One of the biggest benefits of using small, composable utilities is that every developer on your team is always choosing values from a fixed set of options.

Seems ideal but in practice (and a bit of real life experience), it just doesn’t check out. First of all, there isn’t a fixed set of options, thanks to the dynamic brackets [] allowed in most classes. Developers can and will still go with a custom value just like they would with writing a css class property. That means, custom font sizes, colors, widths/height, etc. Even if you don’t allow dynamic values in classes (through linting),

Readability

I’ve read the stories about how wonderful and readible it is. How its so nice not to have to switch to another file 🙄. But as a trade off, anything more than semi-complicated components, you get this:

<button
  class="inline-flex items-center justify-center rounded-md text-sm font-medium ring-offset-background transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:pointer-events-none disabled:opacity-50"
>
  Download
</button>

Bootstrap contribution And Bootstrap finally adds my feature