Tailwind: Suffering From Success

In November 2025, a pull request was opened for the Tailwind website repository to add llms.txt as an endpoint for, you guessed it, providing an LLM-friendly version of the popular CSS framework’s documentation. It first sat idle for a while and the issuer started pinging Tailwind employees for review. After not getting any kind of response, Tailwind’s creator chimed in and laid down some bad news.

Tailwind, for the uninitiated, is a CSS framework that provides so-called utility classes ready-made to quickly and easily style a website by mixing and matching said classes to get decent looking results without ever needing to write a single line of CSS^[1]. It prides itself with only shipping the CSS that is really needed, unlike similar tooling that came before it, like Bootstrap which required you to ship the whole thing with your project and had an opinionated style attached to it. Adam Wathan has laid out his reasoning behind Tailwind’s utility approach in his blog.

The Monkey’s Paw

Adam had this to share as to why the pull request about making it easier for LLMs to barf out Tailwind code wasn’t getting approved:

Have more important things to do like figure out how to make enough money for the business to be sustainable right now. And making it easier for LLMs to read our docs just means less traffic to our docs which means less people learning about our paid products and the business being even less sustainable.

Just don’t have time to work on things that don’t help us pay the bills right now, sorry. We may add this one day but closing for now.

He later clarified:

I totally see the value in the feature and I would like to find a way to add it.

But the reality is that 75% of the people on our engineering team lost their jobs here yesterday because of the brutal impact AI has had on our business. And every second I spend trying to do fun free things for the community like this is a second I’m not spending trying to turn the business around and make sure the people who are still here are getting their paychecks every month.

Traffic to our docs is down about 40% from early 2023 despite Tailwind being more popular than ever. The docs are the only way people find out about our commercial products, and without customers we can’t afford to maintain the framework. I really want to figure out a way to offer LLM-optimized docs that don’t make that situation even worse (again we literally had to lay off 75% of the team yesterday), but I can’t prioritize it right now unfortunately, and I’m nervous to offer them without solving that problem first.

@PaulRBerg I don’t see the AGENTS.md stuff we offer as part of the sponsorship program as anything similar to this at all — that’s just a short markdown file with a bunch of my own personal opinions and what I consider best practices to nudge LLMs into writing their Tailwind stuff in a specific way. It’s not the docs at all, and I resent the accusation that I am not disclosing my “true intentions” here or something.

This feature is so that people can build MORE things with Tailwind in a FASTER and more EFFICIENT capacity.

@mtsears4 Tailwind is growing faster than it ever has and is bigger than it ever has been, and our revenue is down close to 80%. Right now there’s just no correlation between making Tailwind easier to use and making development of the framework more sustainable. I need to fix that before making Tailwind easier to use benefits anyone, because if I can’t fix that this project is going to become unmaintained abandonware when there is no one left employed to work on it. I appreciate the sentiment and agree in spirit, it’s just more complicated than that in reality right now.

Tailwind has become the number one choice to build new web projects with and tons of tutorials include it. Naturally, LLMs are latching on to it because of contextual proximity to the overarching topic; that’s how LLMs work. Ask Claude to code you a web page and it will be written with Tailwind. Tailwind has never been more popular, and its creator is reaping none of the benefits.

It’s another high-profile case of an open source project that, despite becoming an integral part of modern web development, is now struggling to keep itself afloat in the age of “AI”—a Tragedy of the Commons distilled in its purest form and supercharged by a winner-takes-all corporate mentality. Big Tech once again leaves a trail of destruction, ever so efficiently dismantling the foundational data their stochastic parrots rely on to be useful in the first place.

I feel for the Tailwind team. Tools and frameworks are how we throw ideas around how the core technologies can be improved when they serve a need that web devs clearly have. It’s not the framework’s fault that they’re overused because developers are working on the tightest deadlines and companies’ hiring practices are whack. The best path forward for any of these is to make themselves redundant once their approaches find their way back into core technologies.

But this is not what’s happening here. Tailwind has been stripped for parts and left on life support. None of it found its way back into the standards that benefit everyone. If not Tailwind, then it will be another framework that climbs the ranks as developers’ next darling. I don’t believe it’s out of touch of me to say, that’s not what you declare a “win” for the profession—quite the opposite, we’ll all be worse off for it.

The purpose of a tool emerges from how it’s being used. And in the case of “AI” “Coding” “Assistants” their purpose is being an unrelenting parasite.

A Tragedy Within A Tragedy

If you ask me, the economic collapse of Tailwind Labs is only the surface-level tragedy. The deeper one is the culture of avoidance that led to its popularity in the first place. Tailwind saw a very rapid rise to fame, particularly because web developers, for whatever reason, hate CSS with a burning passion. There’s an abundance of comments online from people arguing that they constantly have to “fight the cascade” and declare it a bug that needs fixing.

First of all: skill issue.

Second: Tailwind doesn’t magically make the cascade go away when you use it. Tailwind itself still has to abide by it, it’s still CSS under the hood. All Tailwind really does is provide you with a pre-defined set of tokens, no different from what you would build from a design system a smart designer handed you. Nobody has to agonize over sizing, spacing, colors, typography, border radii, responsive breakpoints and all that stuff. The Tailwind team has just been doing the hard work that you didn’t want to do, for free^[2].

Without knowing the basics of CSS you also won’t get much mileage out of Tailwind. You still need to know how CSS properties interact with one another, like flex and grid and their respective parent and descendant element properties. Furthermore, you can only do the things Tailwind accounts for, which is either severely limiting or you have to come up with a solution the “Tailwind way”. Sure, Tailwind allows you to pass its utility classes custom values or custom properties, but then you’re back to writing CSS, which Tailwind’s stated purpose is to not make you do that.

For all its ease-of-use, Tailwind introduces issues of its own, some of which I keep running into myself in the few instances I use it. Particularly when I need to apply a lot of styles to descendants or pseudo-elements which I have no control over because content is dynamically inserted this approach gets messy fast. Like, sure, Tailwind has modifiers like before: and after: to get to these respective pseudo-elements, but the more utility classes I need to get the look I want, the more the utility class approach makes the class attribute look like I was putting all my CSS in a style attribute.

For example, here’s what the <section> tag used to look like in the beginning:

<section class="mx-auto prose px-safe-offset-4 prose-slate md:prose-lg md:px-safe-offset-6 lg:prose-xl 2xl:prose-2xl dark:prose-invert prose-headings:font-normal prose-p:text-justify prose-blockquote:relative prose-blockquote:border-0 prose-blockquote:ps-16 prose-blockquote:font-normal prose-blockquote:text-slate-700 prose-blockquote:not-italic prose-blockquote:before:absolute prose-blockquote:before:top-0 prose-blockquote:before:left-0 prose-blockquote:before:-z-10 prose-blockquote:before:h-[1em] prose-blockquote:before:text-8xl prose-blockquote:before:leading-none prose-blockquote:before:font-bold prose-blockquote:before:text-sky-500 prose-blockquote:before:not-italic prose-blockquote:before:content-['“'] prose-blockquote:*:before:content-none prose-blockquote:*:after:content-none lg:prose-blockquote:ps-20 lg:prose-blockquote:before:text-9xl 2xl:prose-blockquote:ps-24 2xl:prose-blockquote:before:text-[10rem] prose-blockquote:dark:text-slate-300 prose-figcaption:text-center prose-figcaption:text-balance prose-strong:font-bold prose-strong:text-inherit prose-li:marker:text-inherit! prose-th:font-bold prose-img:mx-auto prose-img:rounded-3xl">
  ...
</section>

I looked at this, threw up in my mouth a little bit, and decided to go against the recommendation in the Tailwind docs, which state(d) that I should not be using Tailwind’s @apply directive to do exactly what I’m about to show you^[3]. @apply combines the styles of all utility classes into a selector of my own choosing (e.g. blockquote { … }), effectively throwing Tailwind’s pluggability out the window. But honestly? I’d rather keep my sanity when I have to go in and edit that monstrosity eventually.

The pedantic among the Tailwind enthusiasts will point out that I’m exacerbating the issue by using the Tailwind typography add-on, and they’d be right! My counterargument to that would be that the main selling point of using Tailwind in the first place is that I don’t have to write a single line of CSS anymore. This ungodly abomination of an unreadable mess of CSS classes is a logical consequence of this premise.

Using @apply I can forgo the use of prose-* prefixes and before: modifiers and instead use the element selector directly, along with native CSS nesting:

blockquote {
  @apply relative mt-10 rounded-xl border-2 border-sky-500 ps-6 pe-6 font-normal text-slate-700 not-italic *:before:content-none *:after:content-none lg:ps-8 lg:pe-8 2xl:ps-10 2xl:pe-10 dark:text-slate-300;

  &::before {
    @apply absolute -top-8 left-4 block h-12 w-20 bg-slate-300 text-center text-8xl leading-none font-bold text-slate-300 not-italic content-['“'] dark:bg-slate-900 dark:text-slate-900;
    -webkit-text-stroke: var(--color-sky-600) 0.25rem;
  }
}

Which cuts down the use on the HTML markup to this:

<section class="mx-auto prose px-safe-offset-4 prose-slate md:prose-lg md:px-safe-offset-6 lg:prose-xl 2xl:prose-2xl dark:prose-invert prose-headings:font-normal prose-p:text-justify prose-figcaption:text-center prose-figcaption:text-balance prose-strong:font-bold prose-strong:text-inherit prose-li:marker:text-inherit! prose-th:font-bold prose-img:mx-auto prose-img:rounded-3xl">
  ...
</section>

Call me old-fashioned, but how is anyone supposed to glean what this element’s purpose is from this? Unless you memorized all the arbitrary class name conventions Tailwind came up with instead of learning CSS proper, you won’t. It’s just replacing one problem with another and putting an additional layer of complexity on top that you have to be familiar with beforehand.

What I also don’t see mentioned anywhere is that Tailwind puts a floor on the browser versions compatible with your website, because of CSS features it uses internally. This breaks the backwards compatibility inherent to web technologies, as Tailwind doesn’t provide necessary fallbacks for graceful degradation! I had to combat that with more complexity by including an additional build step for my blog that runs the Tailwind bundle through Lightning CSS with browserslist targets.

A Blizzard of Innovation

Now, you might argue that Tailwind shines with full front-end frameworks, such as React or Vue.js, not with some blog written with Eleventy in Nunjucks, and I’d totally agree with you! If all your job consists of is coding a shit ton of dashboards in the JavaScript front-end framework de jure of that month, it’s great!

However, the point I’m trying to make here is that Tailwind is to CSS what jQuery was to JavaScript.

jQuery abstracted away the complexities that involved DOM traversal, event handling and animations, which were tedious to deal with in vanilla JavaScript and impossible with CSS at that time. However, at some point, jQuery became synonymous with JavaScript development as a whole. Developers didn’t reach for jQuery because it was the right tool for the job, but because it was more convenient. It became less about knowing the language and more about knowing the tool, which created its own set of atrocities. Knowing the language became an afterthought, a necessary evil in order to get to the tool that “tamed” the language. The irony was not lost on developers.

For what it’s worth, I’ve never written much stuff in jQuery throughout my career and I turned out fine. The best outcome for jQuery was honestly to make itself obsolete by providing a blueprint for improvements to the core JavaScript language itself. It showed that there was a need for these improvements and viable ways to go about it.

I see the same kind of development taking place in CSS with Tailwind. Developers reach for Tailwind because it’s easy and convenient. They think CSS is the evil spawn of Satan that stands between them and their deliverables. There’s nothing inherently wrong with reaching for a tool that gets you 95% of the way there in only a fraction of the time. That’s the whole point. My main concern is that people trying to break into web development will hear other people singing Tailwind’s praises and learn the tool first instead of the underlying language and its core concepts.

When I first heard of Tailwind I had no idea what it was, other than it being another stab at “fixing” CSS. We’ve been through this cycle many, many times, so excuse me if I’m immediately skeptical when every framework of the past 15 years has been the next coming of Christ every 6-10 weeks or so, adding yet another thing I have to have on my resume or risk being “out of touch” with web dev.

The web development landscape is unique in that it is very unopinionated about how you’re allowed to commit tech crimes and make it everybody’s problem, with creative word salads that make you doubt your own listening/reading comprehension. It’s also one of the easier fields of programming to break into and tend to your not-invented-here-syndrome.

The irony in all of this is, that while we’re creating these tools to tackle time-intensive problems faster, we never actually gain any ground. As soon as we do get faster on deliverables, management interprets this increased velocity as a green light to tighten deadlines further or increase the workload. As we reach for more tools to meet the increased demands, it begets even more abstractions and tools we need to familiarize ourselves with. We’re drowning in frameworks not because they make us better, but because we are trying to outrun a pace of work that has no finish line, thus creating a death spiral.

A big part of why I also think this is a problem is that most frameworks and tools that get hyped to hell and back lack a distinct mission statement of what specific problem they aim to solve. Their purpose is simply supposed to be obvious to everybody worth their salt, the aforementioned word salads round out the confusion for new-comers. There is a distinct lack of explainers why and when you should use any given framework in web development, because its developers are more concerned with getting you hooked on the best thing since sliced bread. Tools and frameworks first, core concepts second—if at all. We’re raising developers who don’t know the first thing about thinking like one, as we’re rolling up the ladder behind us!

If you enjoy my writing and would like to show your appreciation, I set up a Ko-fi where you can donate a couple bucks to say "thanks!"