This week, I needed to add a simple hover effect to a button. Nothing fancy. Just change the background color on hover.
I stared at the screen for 30 seconds. My fingers hovering over the keyboard. And I couldn't remember how to write it.
Not because I'm bad at CSS. I've been building websites since 2017. I know CSS. Or I used to.
The syntax just wouldn't come to me. My brain immediately went to hover:bg-blue-600. That's Tailwind. Not CSS.
Then it hit me. I haven't written actual CSS in maybe two years. Everything is Tailwind now. Classes. Utilities. No stylesheets.
And I'm not the only one. Tailwind has over 20 million weekly NPM downloads. That's more than Bootstrap's 4.9 million. The framework is everywhere. Your favourite sites/coding-Agents use.
But here's the question nobody's asking: what happens when we all forget how CSS actually works?
The Takeover Nobody Saw Coming
Five years ago, Tailwind was this weird utility-first framework some people were trying. Most developers looked at code like this:
<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
Click me
</button>
And said "that's disgusting. That's just inline styles with extra steps."
They weren't entirely wrong.
But something happened. Developers started using it. Then they couldn't stop using it. Then they forgot how to build without it.
The data tells the story. According to the State of CSS survey, Tailwind's retention rate is in the high 70s. That means 3 out of 4 developers who try it keep using it.
Compare that to Bootstrap at around 45%. Or plain CSS at... well, people don't "retain" CSS because it's not a choice. It's the foundation.
Except now it kind of is a choice. And developers are choosing Tailwind.
Why Everyone Uses It (Including Me)
I'm not going to sit here and pretend Tailwind is bad. I use it. On every project. My muscle memory is Tailwind classes now, not CSS properties.
Here's why it won:
Speed
You don't context switch between HTML and CSS files. Everything is right there. You see a div, you style it, you move on. No jumping between files. No naming classes. No wondering if .button-primary is already defined somewhere.
Consistency
Your spacing is consistent because you're using predefined spacing utilities. p-4 is always the same padding. gap-8 is always the same gap. No more margin: 23px because you eyeballed it.
No naming things
Naming CSS classes is one of the hardest problems in programming. With Tailwind, you don't name anything. The classes describe themselves. flex items-center justify-between tells you exactly what it does.
Just works
You don't fight specificity. You don't debug why your styles aren't applying. You don't wonder if that class is being overridden somewhere. Tailwind classes just work.
That's powerful. That's why developers love it. That's why I love it.
The Problem Nobody Talks About
But here's what's bothering me. And I think it should bother you too.
We're abstracting away fundamental knowledge
CSS isn't that hard. Flexbox, Grid, positioning, these are core web platform features. They're not going away. But we're building an entire generation of developers who don't know them.
I've interviewed junior developers who can tell me exactly what justify-content: space-between does in Tailwind class form but can't write the actual CSS property.
They know flex items-center but don't know align-items: center.
They know w-64 but have no idea that's width: 16rem or why rem exists.
That's concerning.
The bundle size lie
Tailwind markets itself as producing tiny CSS bundles. "Most projects ship less than 10kb of CSS!"
That's true. Your CSS file is small.
But your HTML is massive. Every element has 5-15 classes. Your HTML files are 2-3x larger than they would be with semantic CSS.
Sure, HTML compresses well. But it still needs to be parsed. The browser still needs to process all those classes.
I ran the numbers on one of our projects. CSS went from 45kb to 8kb with Tailwind. Great! But HTML went from 120kb to 340kb. Net increase: 183kb.
That's not mentioned in the marketing.
You're locked in
Want to switch from Tailwind to something else? Good luck. Your entire codebase is Tailwind classes. Every component. Every page. Thousands of utility classes everywhere.
Migrating away from Tailwind is like migrating away from jQuery was. Possible, but so painful that most people just don't.
You're not learning CSS. You're learning Tailwind. And if Tailwind goes away or falls out of favor, what do you have?
The readability problem
Look at this real code from a production app:
<div class="flex flex-col sm:flex-row items-start sm:items-center justify-between p-4 sm:p-6 bg-white dark:bg-gray-800 rounded-lg shadow-md hover:shadow-lg transition-shadow duration-200 border border-gray-200 dark:border-gray-700 space-y-4 sm:space-y-0 sm:space-x-4">
That's 19 classes on one div. Can you tell what it does at a glance? Nope. You have to mentally parse each utility.
With semantic CSS:
<div class="card">
And in your CSS:
.card {
/* All the styles */
}
Which is more readable? Which is easier to understand for someone new to the codebase?
What Happens If Tailwind Disappears?
This keeps me up at night. Not because I think Tailwind will disappear tomorrow. It won't. It's too big now.
But frameworks come and go. Remember when Bootstrap owned the web? When jQuery was on every site? When Flash was how you made interactive content?
All of those seemed permanent. None of them were.
Tailwind is backed by Tailwind Labs. It's a company. Companies can be acquired, shut down, pivot, or just decide a framework isn't profitable anymore.
What happens to the millions of Tailwind projects then?
You might say "it's open source, the community will maintain it." Sure. But when was the last time you saw a popular framework maintain momentum after losing its core team?
Look at Ember. Look at Backbone. Look at Angular.js (not Angular, Angular.js). All still technically maintained. All basically dead.
I'm not predicting Tailwind will die. I'm saying it could. And if it does, we have an entire industry of developers who can't write CSS anymore.
The Real Controversy (That Nobody Wants to Say)
Here's the spicy take that'll make people angry:
Tailwind is training wheels that never come off.
And that's by design.
When you learn to ride a bike, you start with training wheels. Eventually, you take them off and ride for real.
With Tailwind, you start with utility classes. And you... keep using utility classes. Forever. You never take off the training wheels and write actual CSS.
The framework doesn't encourage you to learn the underlying platform. It encourages you to learn more Tailwind.
Want to do something custom? Extend your Tailwind config(I haven't read much in the newer versions, DO NOT ROAST ME ON THAT, hahaha). Need a new color? Add it to your Tailwind theme. Need a new spacing value? Add it to your Tailwind spacing scale.
Everything pushes you deeper into Tailwind, not deeper into CSS.
And that's brilliant business strategy. Lock-in is valuable. But it's bad for the web platform.
CSS is evolving fast. Container queries, has() selector, subgrid, cascade layers, all these powerful features are landing in browsers.
But how many Tailwind developers know about them? How many are using them?
Tailwind supports some of these through utilities. But you're learning the utility, not the feature. And if Tailwind doesn't support something yet, you probably won't use it.
What I'm Doing About It (And What You Should Too)
I still use Tailwind. Every day. I'm not here to tell you to stop using it.
But I am making some changes:
One day a week, no Tailwind
Friday is my "vanilla CSS" day. If I'm working on something, I write actual CSS. No utilities. Just regular stylesheets.
It's painful at first. But it keeps my CSS skills sharp. And honestly, sometimes it's refreshing.
Teaching juniors CSS first
When I mentor junior developers, we don't start with Tailwind. We start with CSS. Flexbox, Grid, positioning, the fundamentals.
Only after they can build a layout in pure CSS do we introduce Tailwind. So they understand what they're abstracting.
Actually reading CSS specs
I subscribe to CSS updates. I read about new features. I try them in projects. Because CSS is still evolving, and I don't want Tailwind to be my only window into it.
Writing semantic CSS for complex components
For truly complex components, I write actual CSS. Custom properties, calculations, complex selectors. Things that are hard or impossible in utility classes.
This keeps me comfortable in both worlds.
The Uncomfortable Truth
We're in a weird place with CSS right now.
The platform is more powerful than ever. Container queries are game-changing. Cascade layers solve specificity problems. Nesting is finally here natively.
But fewer developers than ever actually write CSS.
Tailwind is winning. The data proves it. The adoption proves it. The community proves it.
And maybe that's fine. Maybe abstraction is progress. We abstracted away assembly language. We abstracted away C. We abstracted away jQuery's cross-browser pain.
Maybe abstracting away CSS is the next logical step.
But I can't shake the feeling that we're losing something important. The ability to understand and manipulate the foundational layer of the web.
When everyone knows Tailwind but nobody knows CSS, who maintains the web platform?
Who contributes to CSS specs? Who files browser bugs? Who pushes CSS forward?
If the answer is "nobody because we're all using Tailwind," that's a problem.
Where CSS Is Actually Heading
While we're all writing flex items-center justify-between, CSS itself is evolving into something more powerful.
Native nesting is here. You can write Sass-style nested selectors in pure CSS now.
Container queries let components be responsive based on their container size, not viewport size. This is huge and Tailwind sort of supports it but most developers don't use it.
The has() selector is a parent selector. You can style a parent based on its children. This was impossible for decades. Now it's real.
View transitions API makes page transitions smooth and native. No JavaScript framework needed.
Cascade layers give you fine-grained control over specificity. You can finally organize your CSS without fighting specificity wars.
All of this is native CSS. Browser-level features. No build step. No framework. Just works.
But how many developers are using these? How many even know about them?
Tailwind adds utilities for some of this. But slowly. And only when it makes sense for their utility-first model.
Meanwhile, native CSS is moving faster than any framework can keep up with.
The Question We Should Be Asking
Not "should I use Tailwind?" That ship has sailed. Most of us are using it or will use it.
The question is: "how do I use Tailwind without forgetting the platform?"
Because that's the real risk. Not that Tailwind is bad. But that it's so good that we stop learning what's underneath.
And when the next big thing comes (and it will come), we'll be unprepared.
We'll be Tailwind developers, not web developers.
And that difference matters.
My Honest Take (After 3 Years of Tailwind)
I don't hate Tailwind. I use it every day. It makes me faster. My team is more productive with it.
But I'm worried about the industry. About junior developers who think CSS is just Tailwind classes. About codebases that are so dependent on one framework that migration is impossible.
About a future where "front-end developer" means "knows Tailwind" instead of "knows the web platform."
Maybe I'm wrong. Maybe this is just progress and I'm being nostalgic about writing CSS files like an old man yelling at clouds.
But I don't think so.
I think we're trading short-term productivity for long-term knowledge. And that trade-off only makes sense if Tailwind stays dominant forever.
Which is a big assumption.
What You Can Do
If you're using Tailwind (and you probably are), here's my advice:
Don't stop learning CSS. Spend time with the actual properties. Understand what you're abstracting. Read CSS specs. Try new features.
Teach CSS to juniors before Tailwind. Make sure they understand the foundation before adding the abstraction layer.
Write some vanilla CSS occasionally. Keep your skills sharp. You might need them.
Stay aware of native CSS evolution. The platform is moving fast. Don't let Tailwind be your only window into it.
Build escape hatches. Don't make your entire codebase 100% Tailwind. Have some custom CSS. Make migration possible, even if unlikely.
Question the framework. Just because Tailwind says something is "best practice" doesn't mean it is. Think critically about what you're building.
The Bottom Line
Tailwind won. The data proves it. The adoption proves it. If you're arguing against Tailwind in 2025, you've already lost.
But winning doesn't mean it's perfect. And popularity doesn't mean it's the final answer.
CSS is the platform. Tailwind is a tool. Don't confuse the two.
Use the tool. But respect the platform. Learn the platform. Contribute to the platform.
Because when the next framework comes (and it will come), the platform will still be there.
And you'll need to know it.
What's your take? Are you forgetting CSS too? Or am I overthinking this?
Drop your thoughts. Let's argue in the comments like developers do.
Elvis Sautet
Follow me on x at @elvisautet
Senior Full Stack Developer | Still Writes CSS Sometimes
If this made you uncomfortable, good. Share it anyway. We need this conversation.
Top comments (0)