Last month I removed Tailwind from a side project. And you know what? Nothing broke.
That was more unexpected than I had anticipated. The build step I had been holding onto for years was actually unnecessary.
The platform grew up while we weren't looking
Something nobody really celebrated the release of, Vanilla CSS just went ahead and added the things that many of us were needing libraries to grab for us.
By the end of 2024, native CSS nesting was supported by all the major browsers. This means that you could use the code .card { .title { ... } } without the need for PostCSS, Sass, or any other preprocessor.
The :has() parent selector achieved approximately 94-98% cross-browser support (Baseline: Widely Available). You want to style a container based on its contents. No JavaScript required, no class-toggling gymnastics.
What about @layer? It eliminated the specificity wars. You decide which styles have higher precedence in the cascade, so you don't have to resort to !important like Tailwind's overrides might have led you to believe.
Utility classes solved a problem that's already fixed
Tailwind was necessary. The CSS cascade was a footgun, nesting required a preprocessor, and scoping was a disaster.
All of those pain points have a native solution today. The abstraction was no longer necessary.
This became evident thanks to a popular developer forum post in July 2026. A user took an entire Tailwind dashboard and re-implemented it in plain CSS. It functioned.
There's also an AI angle that supports this. A January 2026 JavaScript in Plain English writeup asked Claude to build something in modern vanilla CSS. The result: "It worked. Perfectly. First try. And the output was cleaner than the Tailwind equivalent."
The numbers aren't kind either
Tailwind version 4 was released in January 2025. It included "Oxide," which is a Rust rewrite from the ground up. It had HMR that was less than a millisecond with a 10-14x improvement from v3. This was engineering at its finest. 👏
But a March 2026 Leaper.dev benchmark on an M3 MacBook Pro summed up the catch perfectly: "vanilla CSS with no processing step still wins, there's simply nothing to compile."
Nothing can be faster than not having to run anything.
The bundle sizes tell the same story. In one landing page benchmark:
→ Tailwind: 14.78 KB total (8.67 KB HTML + 6.10 KB CSS)
→ Vanilla: 8.45 KB total (6.28 KB HTML + 2.16 KB CSS)
That's a Tailwind bundle that is 75% heavier, for a landing page! The utility classes swell your HTML, and the generated CSS swells on top.
Someone's already proving it at scale
If you believe this rule only applies to small projects, consider 37signals. They applied this philosophy to three products they shipped: Campfire, Writeboard, and Backpack.
Almost 14,000 lines of vanilla CSS spread out over 105 files. No build tools.
This was not a quick project done by a single developer over a weekend. This was an official company delivering actual products, and they decided not to use a compilation step in their CSS process.
Who should actually care
I'm not saying tomorrow you should rip Tailwind out of a 50-person codebase. If your team has muscle memory, shared conventions, and a working design system, the switching cost is real.
However, the majority of us are not that team. We are individual developers and small startups who have always included a build step automatically.
Here's my take:
→ Solo project or small site? You probably don't need the toolchain anymore.
→ Big team with an entrenched system? Stay put, the ergonomics still pay off.
→ Starting fresh in 2026? Try native first before you reach for the abstraction.
It's not that Tailwind is a bad tool. It's that the problem it solved for us initially was temporary, and most of us never stopped to re-evaluate.
The takeaway
We create tools to address specific issues we're facing. But sometimes, even after the problem has been solved, or no longer exists, we continue using the same tools.
And that's when problems can arise. Interestingly, Vanilla CSS eventually "caught up".
By the time the CSS pain points felt worth fixing, native CSS had already added the features to solve them, so a lot of the workaround code we relied on was no longer necessary.
Most modern browser layout issues had a habit of solving themselves if you just gave them a little time.
Have you had the chance to use native CSS since nesting and :has() shipped, or are you still advocating for a build step because that's what you're used to?
Top comments (11)
Interesting perspective. Modern CSS has definitely closed the gap with tools like Tailwind, especially with nesting, :has(), and cascade layers.
I think the bigger shift is not Tailwind **vs Vanilla **CSS, but choosing the right abstraction for the project. For a small app, native CSS can be cleaner and faster. But for larger teams, Tailwind still provides value through consistency, conventions, and faster development.
The best tool is the one that solves the current problem, not the one we are simply used to using.
Yeah that was what I was wondering about - doesn't Tailwind solve more problems than just the 3 'technical' ones the author mentions - things on a more "conceptual" (or maybe "process") level?
And creates a boatload of other problems too...
As always, use the right tool for the job - good to hear that "vanilla" (JS and CSS) are ever getting better, it gives us options ...
In my experience, Tailwind isn't the right tool for basically anything, except fast prototyping. I.e. something that AI now does for you anyway. And even in that case, there are less obtrusive tools for the job.
The main argument for using Tailwind seems to be (especially in a corporate/team setting) is that it relieves you from the task of designing and setting up a CSS "structure"/architecture (naming, design 'tokens', etc) ...
It's a "standard" which people can drop into a project and run with - everyone in a team (assuming they know Tailwind) will right away be familiar with it ...
That's the main argument in favor of TW - and isn't there something to that?
The argument is not that TW is intrinsically capable of anything which Vanilla CSS isn't ...
It's more that "vanilla" CSS offers more 'degrees of freedom' and less of a baked in 'structure', hence more ways of shooting yourself in the foot and creating an unmaintainable mess (if you don't know what you're doing) ...
I agree that people who "really know what they're doing" probably don't need Tailwind ...
P.S. and yes, AI can probably also set up a good structure (with good naming, design tokens, etc) for you, making the argument for TW less convincing nowadays ...
The problem is that Tailwind is not a standard in any way, shape, or form. It's an arbitrary layer on top of CSS that's been conceived by one author, and answers the needs of his own professional experience - and not the cooperative effort of representatives of the whole industry. It changes significantly (with breaking changes) from one major version to another.
If you want a pre-made, well-thought design token there are alternatives. The first that comes to mind is Open Props. But then again, LLMs now can create one for you, if you just give them a couple of colors, a font and some directives.
Tailwind doesn't even save you from learning CSS (for the good or bad) or even from knowing what the cascade is. It doesn't save on total byte transfer - on the contrary, payloads increase. It doesn't even safeguard you to make a mess anyway because you can specify custom values in a (rather messy) syntax.
The main benefits about using Tailwind for me were:
I never thought of Tailwind as being necessary or that there were any inherent problems with CSS; Tailwind can make some things easier at the expense of others. I had previously used BEM, which was solving the issue of removing the complexity of the cascade, but now you had to name everything and you miss out on the inherent benefits of cascading CSS.
As always there are tradeoffs to using frameworks versus the vanilla languages.
Yeah good points, we shouldn't be too quick to dismiss one approach over the other - the way I see it, Tailwind solves the problem of CSS having "too many degrees of freedom", it enforces a 'system' ...
I might be behind on 37signals news, but weren't Writeboard and Backpack retired years ago? The recent no-build example I know from them is the new Campfire they sell through Once, so I'm curious where the three products and 14,000 lines figure comes from.
I don't use Tailwind anymore or anything like it. I don't even use class= or style= anymore. The HTML is more readable if it's just the semantic element name and a directive or two to specify behaviors or appearance like inputs button "styles".
See docs.vitre-ui.com/ which is a simple example of a bit of CSS for standard elements that makes any default HTML side look much better. That site is written using it. NO class=, NO style=, just elements and elements like section, article, aside, nav, header, and footer. You can use it as-is or specify a site.css file that overrides some CSS variables for your preferred colors, etc. Still fairly shallow in options but I've used it on 4 or 5 sites so far.