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 (3)
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.
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.