Introduction
Hey there! I hope you’re doing well. I’m back with my second blog article, and I really hope you’ll enjoy it even more than the first one.
My story with development starts very early, and with web development in particular. By the age of 7, I was already deeply into computers, despite the rough telecom infrastructure where I lived (we didn’t even have 3G, we were still on 2G, if I remember correctly).
But things really started when I turned 14. That’s when I met the person who is a brother to me today: Anselme Ouattara. He was invaluable in my growth, and he still is. His support and his guidance were essential to me. Beyond being a brother today, he was a demanding mentor, one who always expected a lot from me, and still does.
Learning took me quite a while, and the hardest part for me was CSS, even though it has since become a foundation I’m fairly comfortable with. Back then, since it wasn’t all that easy, I wanted to skip ahead and jump straight into a CSS framework: Bootstrap. Thankfully, Anselme set me back on the right path. He made it very clear to me, by every means he had, that I hadn’t acquired the CSS fundamentals yet, and that using Bootstrap at that stage would hurt me more than help me in the long run. Those few words pushed me to genuinely learn and master CSS… but at the same time, to hate anything that looked like a CSS framework. I also think it came from the videos I was watching, which trashed Bootstrap quite a bit, and from the ego I had built up from being good at CSS when many others weren’t.
And it’s precisely that rejection of CSS frameworks, forged in my early days, that would later crystallize on one very specific target: Tailwind.
Why I Started to Hate Tailwind CSS
As I said in the introduction, my hatred first targeted Bootstrap, simply because Tailwind didn’t exist yet at the time. But once the Bootstrap hype died down, we reached a point where Tailwind started to grow considerably (2020-2021). It was all anyone talked about, to the point where I saw people who didn’t even have CSS basics trying to learn Tailwind directly.
And there were three things I just couldn’t wrap my head around:
- Why go against the rule that says you separate CSS from HTML, with well organized, readable class names?
- Why was everyone around me so hungry for every new thing? Just a shiny effect?
- How were they managing to maintain their codebase with the pile of classes Tailwind pushed them to stack up?
All of that only fueled my hatred of CSS frameworks a little more. And since Bootstrap had become almost nonexistent and everyone had switched to Tailwind, that resentment naturally landed on Tailwind.
I spent several years refusing to hear anything about that tech, clearly more than five years. Anything remotely related to Tailwind instantly lost my interest and didn’t get a single second of my attention.
That’s how, for example, I completely missed interesting products like shadcn/ui, which I actually find really cool today.
So yes, as the title of this article announces: I really did hate Tailwind. But that’s no longer the case, because something did happen that changed my view of this tech… and laid bare every prejudice I was carrying about it.
What Finally Changed My Mind
What truly changed my view of Tailwind was moving to France for my Master of Science in Information Systems Architecture. In my apprenticeship, I was in close contact with Tailwind CSS almost every day of the week, and at school it was the default choice for styling our project interfaces too. I wasn’t exactly thrilled about that decision, but I had to get used to it for the sake of the projects I was working on.
Over time, I realized it wasn’t nearly as horrible as I thought, and that things had also evolved a lot to make Tailwind far more intuitive and appealing. My hatred started fading on its own. I even watched videos about the reasons behind its creation, and I traced it all the way back to Adam Wathan’s article on utility classes and “separation of concerns”, the very one that gave birth to Tailwind and that answers, point by point, the first objection on my list. I had real, in depth conversations with people who had been using it for a long time, and browsing the official showcase, I realized Tailwind was anything but a toy: ChatGPT, Shopify, Vercel, the Microsoft .NET site, the Google I/O site and even NASA’s Jet Propulsion Laboratory site rely on it. Needless to say, I had no reason left to keep avoiding it.
One of those videos really stuck with me: the Fireship one, which honestly weighs the pros and cons of Tailwind. If you’re still on the fence, I recommend it, it has the merit of not selling a dream and of putting the real tradeoffs on the table:
But beyond the comfort, what really tore down my prejudices was understanding two things Tailwind solves that I had never seen coming.
The first one is that the shipped CSS never grows. With classic CSS, your stylesheet only swells as the project goes on: every new screen adds its own rules, and nobody ever dares delete anything for fear of breaking a page somewhere else. As a result, you carry tons of dead code around. Tailwind works the other way around: its engine only generates the classes actually used in your markup. Whether your app has three pages or three hundred screens, the final CSS stays tiny, in the range of a few dozen kilobytes.
The second one is the end of specificity and naming wars. This is the real nightmare of CSS at scale, the one big companies describe: the cascade, stacked !important, BEM, the dread of coming up with yet another class name. With classic CSS, you can break component B just by touching the style of component A, at the other end of the file. With Tailwind, one class maps to one property, specificity is constant, and there’s no more action at a distance:
<!-- Classic CSS: the style lives elsewhere, you have to invent a name,
fight the cascade, and pray nothing else uses .card__title -->
<h2 class="card__title">...</h2>
<!-- Tailwind: the style is right here, local, no specificity and no name to invent -->
<h2 class="text-lg font-semibold text-slate-900">...</h2>It looks trivial on a heading, but at the scale of a large application, with dozens of components, never having to fear that a style change breaks another one completely changes your relationship with the code. The official docs actually dedicate a whole page to this reasoning, and it’s worth the read if you want to dig deeper.
That leaves verbosity, and that was my strongest objection: how do you maintain a codebase where every tag drags twelve classes around? I only understood the answer through practice: the unit of factorization isn’t the class, it’s the component. Nobody copies the same stack of classes forty times. You write your <Button> once and for all, and the “soup” only exists in one place, where the component is defined. Everywhere else, you read <Button variant="ghost">. And where verbosity does remain, it’s local: the style is right in front of me, instead of being three files away. Verbose isn’t the same as complicated. Add to that the fact that deleting the markup deletes the style along with it, and the maintenance nightmare I feared never materialized. AI, which handles Tailwind very well, just added comfort on top.
Why Tailwind Became My Default Choice
But nothing beats practice when it comes to forming a real opinion. And Tailwind is at the heart of most of what I build today:
- Intrivio (intrivio.cv, app.intrivio.cv): my generator for resumes and cover letters optimized for applicant tracking systems (ATS), with AI powered customization and professional PDF export. Here too, the entire interface is built on Tailwind.
- Rigma (app.rigma.io): the platform I’m building for my company. It’s probably the most demanding project on the list, with a rich interface and many components, and Tailwind handles the load perfectly day after day.
A small showcase site on one side, a full business application on the other: at every scale, Tailwind saved me time without ever getting in the way, the exact opposite of what I feared back then. From using it on these projects, it went from “imposed tech” to first reflex. And if I had to sum up why, it would come down to a few points.
First, speed. I style directly in the markup, without juggling between my HTML and a CSS file, without inventing yet another class name. I think the interface, I write it, I see it, all in one place. What I used to see as sacrilege (mixing style and structure) became my single biggest source of speed.
Then, consistency. Tailwind enforces a design system by default: a spacing scale, a color palette, a typography scale. No more margin: 13px out of nowhere. Everyone draws from the same vocabulary, and the result stays coherent from one component to the next, from one project to the next.
There’s also maintainability, the very thing I dreaded so much at the start. On a large business application, the real question isn’t writing style, it’s daring to touch it six months later. Picking up a component written by someone else, seeing everything in one place, changing it without having to map out which rule comes from where: that’s where I definitively let go of my prejudices.
Finally, the ecosystem. shadcn/ui, Headless UI, the countless ready to use components, the perfect fit with AI that “understands” Tailwind better than any homemade convention… All of that means that today, starting a project without Tailwind would take an almost conscious effort.
In short, it’s no longer a choice I weigh every time: it has become my default starting point. And coming from someone who spent more than five years hating it, that means something.
What I’d Tell My Past Self
If I could go back and talk to the 14 year old kid I was, I wouldn’t take everything back. There’s one thing I’d tell him word for word: learn CSS the hard way, thoroughly, with no shortcuts. That standard I held myself to, that will to understand what actually happens under the hood before delegating anything to a tool, is probably the best decision of my journey. Even today, if Tailwind feels intuitive to me, it’s precisely because I know exactly what CSS it generates behind each class. That foundation, I’d impose on him again without hesitation.
But there’s one thing I’d say differently. That harshness I imposed on myself, I had ended up turning it against tools and against people. Hating poorly mastered CSS, fine, but looking down on frameworks and on those who used them made no sense at all. A framework isn’t an enemy, it’s a tool; and someone who picks Tailwind isn’t “cheating”, they’re simply making a different choice than mine. So I’d tell him: keep your standards for yourself, but be far gentler toward CSS frameworks and toward the people who adopt them.
Conclusion
There you go, you know the whole story. The story of a developer who hated Tailwind for more than five years, on principle, out of ego, out of distrust of anything that remotely looked like a CSS framework, and who today has made it his default starting point on every single one of his projects.
What I take away from it, deep down, isn’t so much “Tailwind is good” or “Tailwind is bad”. It’s that my strongest technical certainties were mostly prejudices I had never really confronted with reality. All it took was being forced to work with it daily for everything to collapse, and for me to discover a tool that, far from slowing me down, saves me precious time at every scale.
So if you’re carrying around a tech you hate without ever having really tried it, take this as an invitation: give it an honest chance. You might be surprised by what you find, just like I was.
Thanks for reading this far. See you very soon for the next article.