I was also tired of getting dragged in every Tailwind related conversation on the Svelte Discord. Apparently people thought it would be fun to mention me every time Tailwind came up. I guess I brought upon myself with these blog posts:
- Why you’ll probably regret using Tailwind
- Thoughts on Tailwind CSS
- Hey, your API surface is causing unnecessary complexity
(All I was trying to do was making people reconsider their CSS strategy instead of blindly going for the new popular framework.)
Now, getting blocked by a person, that’s one thing. I guess Adam’s coping strategy with criticism was an “I don’t want to hear it.”
Needless to say, you then create your own bubble of truth. I understand you want your social media experience to be pleasurable. I’ve been getting into some stupid Twiitter fights recently and they can get you annoyed.
The weird thing is we never even had an interaction or anything on Twitter. Then there comes the point where I have to use Tailwind for work and I am blocked by an offical account and – that feels kind of stupid? Getting blocked by a company entity for having an opinion is kind of… strange?
It’d be like my bank wouldn’t want me to be a customer anymore after I critiqued their app (post in Dutch). Sorry. Being critical of these things is part of _my job_.
You know how sometimes you fight something and it just doesn’t die? And then it just becomes part of the ecosystem? I think Tailwind is a bit like that. There’s no going back. It’s just part of the system now.
Just like I don’t like React I will probably never really like Tailwind.
But that doesn’t mean that I can’t be a professional and write the best Tailwind code I can if that’s what’s asked of me. And try to find the good stuff in there, which is what this post is about.
It’s the same with React. The rest of the world already decided a long time ago that React is a good idea. I don’t like it. I think the syntax is too complex and too many parts of the ecosystem try to reinvent the wheel. But there’s definitely good parts to React. Some of the most exciting frameworks I’ve found recently are all written in React.
So generally, if I don’t like a technology, I now have 2 choices: complain about it and try to avoid it or try to deal with it the best way I can.
So after battling Tailwind for a while, a new project came up, where Tailwind was requested as a part of the development.
I was tired of fighting it and I remembered what people argued in the original criticism, “have you actually really used it?” – upon which I argued – “I don’t need to use it to know that it’s bad! I tried it for a two hour experiment and I already know!”
Now. of course a two hour experiment is not the same as real-world experience. It’s not the same as giving it a try in a codebase with multiple people. It’s also not the same as being a deliverable towards a group of people who don’t know much CSS.
You see, it’s all easy to claim the right path for years, but if in the end your deliverable is too difficult to change or maintain, maybe you should question your methods.
I can forever claim that people should just learn CSS but if that happens to be a difficult thing, maybe we should try to make a deliverable that is more… malleable. Even if it creates some maintainability problems.
I know the devs at Spatie love Tailwind; a developer I respect also loves it. So surely there must be something there?
Long story short, the stars were aligned to give Tailwind a real try.
The Tailwind authors themselves argue that all the Tailwind overload of classes a shock at first but gets productive soon.
I don’t know if I was entirely productive at first because I first had to shake up my dev stack to add in support for PostCSS, PurgeCSS and figure out all kinds of Tailwind specific things. That was part of my original criticism – people kept bring up config & build problems in the Routify Discord – but I just happened to be in a productive dev tooling month, and built in all the tooling so I could run a Tailwind-based workflow in earnest.
And after that, going into the work of implementing a UI I had to admit. There is something here.
I think there’s also something like Tailwind: The Good Parts.
- Documentation is extensive and well written
- I love the ⌘+K shortcut
- The new Headless UI looks great and solves a real problem
- The Tailwind UI project’s look for their component has some good visual choices (although Tailwind’s techniques make that look kind of baked in, especially if you use Tailwind UI)
- Tailwind UI’s Figma file has the highest level of quality I’ve ever seen in an external Figma file
- HeroIcons looks good
- The underlying idea of design tokens to customize design output is great; design tokens are now being discussed to be a standard; having a centralized config that builds constraints into CSS systems will help maintainability. A framework that promotes those ideas can be a boon.
Now, time will tell if I’ll really regret going down this route. But for now, I’ll happilly accept Tailwind-based projects and learn as much as possible.
From a team perspective, it’s not just my opinion that counts. It’s the combination of opinions from the client (we often work directly with the dev team), my colleagues and myself.
If more projects come up, and as we learn more about Tailwind, I’m sure I’ll have something new to say. But for now I chose to embrace it as a new workflow. Just don’t say I never warned you if code become unmaintainable in the end.