Comment by heliumtera
1 day ago
Tailwind Labs relied on a weird monetization scheme. Revenue was proportional to the pain of using the framework. The sudden improvement in getting desired UI without relying on pre-built templates killed Tailwind Labs.
There are many initiatives in a similar spot, improving your experience at using Next.js would hurt Vercel. Making GitHub actions runners more reliable, stable and economical would hurt Microsoft. Improving accessibility to compute power would hurt Amazon, Microsoft and Google. Improving control and freedom over your device would hurt apple and Google.
Why should we be sympathetic to the middleman again?
If suddenly CSS became pleasant to use, Tailwind would be in a rough spot. See the irony?
"Give everything away for free and this people will leave technology", geohot said something like this and I truly appreciate. Technology will heal finally
> If suddenly CSS became pleasant to use, Tailwind would be in a rough spot.
CSS is pleasant to use. I know I find it pleasant to use; and I know there are quite a few frontend developers who do too. I didn't pay much attention to tailwind, until suddenly I realized that it has spread like wildfire and now is everywhere. What drove that growth? Which groups were the first adopters of tailwind; how did they grow; when did the growth skyrocket? Why did it not stay as niche as, say, htmx?
People like tailwind because it feels like the correct abstraction. It helps you colocate layout and styling, thereby reducing cognitive load.
With CSS you have to add meaningless class names to your html (+remember them), learn complicated (+fragile) selectors, and memorise low level CSS styles.
With tailwind you just specify the styling you want. And if using React, the “cascading” piece is already taken care of.
The point of CSS is specifically to separate styling and semantics, so that they are not tightly coupled.
If you were writing a blog post you would want to be able to change the theme without going through every blog post you ever wrote, no?
If I'm writing a React component I don't want it tightly coupled to its cosmetic appearance for the same reason. Styling is imposed on elements, intrinsic styles are bad and work against reusability, that's why we all use resets is it not?
I do agree that the class name system doesn't scale but the solution is not to double down on coupling, but rather to double down on abstraction and find better ways to identify and select elements.
15 replies →
disagree. Colocation seems great when authoring, but it comes at a big cost of downstream tech debt
there could be better ways to ease the burdon of naming things, while preserving cascade and the actual full features of CSS
Tailwind is a mirage, a shortcut to not having to do the important stuff by stacking wrappers on top of wrappers and redundancy
And the "fragile" part is exactly the same thing with tailwind, it all remains low specificity class names
1 reply →
Those are the same selling points as CSS-in-JSS libs like Styled Components. Or CSS Components.
Except your last point about "low-level CSS styles" which I'd argue is a weak point. You really should learn the underlying CSS to gain mastery of it.
Not arguing for one thing over another, just saying Tailwind really never had anything to offer me personally, but maybe if I wasn't already proficient in CSS and the other 2 options didn't exist it might hold some appeal for me.
5 replies →
Imo CSS is not pleasant to use, but Tailwind is at least as bad and furthermore is bad in addition to the CSS badness which it does not fully replace. It is a mystery to me as well how it got so popular.
(I know many people disagree, which is fair enough.)
Writing CSS manually was never all that pleasant for me, mostly the part about debugging it when it doesn't do what I want.
So I tried Tailwind and it seemed to help.
But now that Claude Opus 4.5 is writing all my code, it can write and debug CSS better than I can use Tailwind. So, CSS it is.
Debugging CSS nowadays is way easier than even 5 years ago. There are a lot of cool browser debugging tools for animations, z-indexes. The browsers have come a long way since firebug. Definitely look into both chrome or firefox, their tooling is great. Especially firefox, they have debugging tools where you can create css shapes in the browser and save them. Very handy for those artsy fartsy sites.
Claude can also write and debug tailwind for you! :)
I used plain CSS for more than a decade and felt the benefits of Tailwind within 10 minutes of getting started. What fueled the growth of Tailwind is that it makes web development palpably easier.
What were the benefits that you felt instantly? I still don't feel anything and would prefer plain CSS over Tailwind any day.
21 replies →
Do you remember what made it click for you? What was the hard part of writing plain CSS that tailwind made significantly easier?
10 replies →
> What drove that growth?
It is a natural fit with component-based frontend frameworks like React. You keep the styles with the component instead of having to work in two places. And it’s slightly nicer than writing inline styles.
The core CSS abstraction (separating “content” from “presentation”) was always flimsy but tailwind was the final nail in that coffin.
Then of course LLMs all started using it by default.
You've been able to keep the styles in the component well before tailwind turned the class attribute into ersatz inline styling. CSS-in-JS has been around for a decade, and there are myriad options for react. Vue and Svelte have them built in.
Fe devs who refuse to learn css and instead use tailwind have always struck me as incredibly odd. It's like a carpenter who refuses to use a hammer because they hit their thumb once as an apprentice
I wrote this piece on tailwind a few years back, and little seems to have changed https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...
It’s interesting to me because CSS is very stable. It doesn’t really change that often. It’s great foundational knowledge to have for people who build for the web.
1 reply →
backend devs needing to be fullstack but consider frontend to be beneath them
I'll give my guess - it's because of rhe "fullstack" bullshit.
I am a backend developer. I like being a backend developer. I can of course do more than that, and I do. Monitoring, testing, analysis, metrics, etc.
I can do frontend development, of course I can. But I don't like it, I don't approach it with any measure of care. It's something I "unfortunately have to do because someone who is not a developer thought that declaring everyone should be doing everything was a good idea".
I don't know how to do things properly on the front end, but I definitely can hammer them down to a shape that more or less looks like it should. For me, shit like Bootstrap or Tailwind or whatever is nice. I have to spend less time fiddling with something I think is a waste of my time.
I love working with people that are proper front end developers for that reason, and I always imagined they would prefer things more native such as plain CSS.
> CSS is pleasant
So is SQL. To me. But some otherwise rational people have an irrational dislike of sql. Almost like someone seeking to seal a small bruise with wire mesh because bandaids are hard to rip off. The consequence shows with poorly implemented schema-free nosql and bloated orm tools mixed in with sql.
But some folks just like it that way. And most reasons boil down to a combination of (1) a myopic solution to a hyper specific usecase or (2) an enterprise situation where you have a codebase written by monkeys with keyboards and you want to limit their powers for good or (3) koolaid infused resume driven development.
Decades of SQL hate eviscerated in one comment! /s
Is CSS pleasant in teams of fullstack (not CSS specialists)? Not in my experience. It becomes a maze of Chesterton's fences.
I would have understood if tailwind got popular primarily among full-stack or backend developers: people who have neither time nor interest to learn CSS deeply. But, what contradicts this expectation is that one still needs to acquire CSS knowledge to use tailwind, and that some front-end developers seem to prefer it as well. Although I still cannot tell whether there are more front-end developers who prefer tailwind over plain CSS than the other way around.
4 replies →
Tailwind is just bootstrap with marketing budget
nah
I haven’t seen this mentioned much, but Tailwind’s rise closely followed a shift away from runtime CSS-in-JS toward build-time, deterministic styling.
Many JSX-era libraries (MUI, styled-components, Emotion) generate styles at runtime, which works fine for SPAs but creates real friction for SSR, streaming, and time-to-first-paint (especially for content-heavy or SEO-sensitive domains).
As frameworks like Next.js, Vue, Svelte, Angular, and now RSC all moved server-first, teams realized they couldn’t scale entire domains as client-only SPAs without performance and crawler issues.
Tailwind aligned perfectly with that shift: static CSS, smaller runtime bundles, predictable output, and zero hydration coupling. It wasn’t about utility classes. It was about build-time certainty in a server-rendered world :)
Your examples, Vue and Svelte, give you build-time predictable output with scoped CSS without Tailwind. All the benefits and none of the downsides!
That’s not at all why I bought Tailwind Plus. I bought it (at work) to have a solid collection of typical components and UI patterns, mostly expertly designed with a lot of attention to detail, to use as inspiration and as a shared language with other frontend devs and designers. I rarely (if ever) actually copy pasted any of their HTML or Tailwind styles. It’s mostly used as reference and inspiration. The fact that it’s implemented in Tailwind is mostly irrelevant (Tailwind really isn’t hard to use, especially after your first couple of small projects).
> If suddenly CSS became pleasant to use
Not being sarcastic, but this will never be. CSS is a perfectly functional interface, but the only way it becomes less annoying is when you abstract it behind something more user friendly like tailwind or AI (or you spend years building up knowledge and intuition for its quirks and foibles).
We have decades of data at this point that fairly conclusively shows that many people find CSS as an interface inherently confusing.
I agree. I actually think CSS (and SQL or other “perfectly functional” interfaces) hold some kind of special power when it comes to AI.
I still feel that the main revolution of AI/LLMs will be in authoring text for such “perfectly functional”-text bases interfaces.
For example, building a “powerful and rich” query experience for any product I worked on was always an exercise in frustration. You know all the data is there, and you know SQL is infinitely capable. But you have to figure out the right UI and the right functions for that UI to call to run the right SQL query to get the right data back to the user.
Asking the user to write the SQL query is a non-starter. You either build some “UI” for it based on what you think is the main usecases, or go all in and invent a new “query language“ that you think (or hope) makes sense to your user. Now you can ask your user to blurb whatever they feel like, and hope your LLM can look at that and your db schema, and come up with the “right” SQL query for it.
Hey! Don't you dare to compare SQL and CSS. SQL is not a cobbled together mess of incremental updates with 5 imperfect ways of achieving common tasks that interact in weird ways. Writing everything in SQL-92 in 2026 is not gonna get you weird looks or lock you out of features relevant for end users. If writing SQL for your problem feels difficult it's a good sign you ought to look at alternatives (eg. use multiple statements instead). Writing the right CSS being difficult is normal.
1 reply →
Things like flexbox have made CSS indescribably better and easier to use than it used to be. It's still bad, but degrees matter a lot.
As a fullstack dev, I couldn't do pixel-perfect CSS 10 years ago, and today I can. That's a lot of progress.
I was already using flexbox ten years ago. And if the goal was pixel-perfect layout, I could do that twenty years ago using `position: absolute`.
I would instead characterize the recent developments in CSS as enabling good layout even when there are major unknowns in your content. It was always easy to write CSS tailored to one set of content (say, one style of toolbar in your UI), but it has become possible to write generic CSS (say, a generic toolbar component where the icons are unknown, the width and height are also unknown).
It's getting better (in a C++ kinda way), certainly, but...
It's ultimately still driven my matching "random" identifiers (classes, ids, etc.) across semantic boundaries. Usually, the problem is that the result is mostly visual which makes it disproportionately hard to actually do tests for CSS and make sure you don't break random stuff if you change a tiny thing in your CSS.
For old farts like me: It's like the Aspect-Oriented Programming days of Java, but you can't really do meaningful tests. (Not that you could do 'negative' testing well in AOP, but even positive testing is annoyingly difficult with CSS.)
EDIT: Just to add. It's an actually difficult problem, but I consider the "separate presentation from content" idea a bit of a Windmill of sorts. There will always be interplay and an artificial separation will lead to ... awkward compromises and friction.
CSS has come a long way. I used to include Bootstrap in all of my projects, effectively by default. Now it's obsolete. Especially with Grid and Flex.
Do people even know what they can do with CSS these days?
https://lyra.horse/blog/2025/08/you-dont-need-js/
FWIW the radio button vedi vidi vici example has the round radio buttons overlaid with the text on Firefox.
> Making GitHub actions runners more reliable, stable and economical would hurt Microsoft.
Can you explain this one a bit? I know some folks who would absolutely increase their spend if Actions runners were better. As it stands I've seen folks trying to move off of them.
If they were twice as efficient, you would only need to run half as many and spend less.
Gh actions runners had a dubious implementation of sleep that would cause runners to hang on 100% usage for weeks/months. A simple fix was proposed and neglected for 10 years. This discussion resurfaced recently with zig abandoning GitHub entirely and criticizing this specific issue. A fix was them merged following an announcement that self hosted runners will now be charged by the minute. Of course this two facts are totally independent but yeah, yeah, sure.
How does this support your point? If we're saying "they fixed it because there was pressure to"... okay? That's the parents point - tons of people are going to move off over bad performance, and Github was incentivized to fix it when people started moving off.
If Github's incentive was to keep it slow... we wouldn't have seen exactly what you're describing.
4 replies →
I know I’m echoing others’ responses but CSS in 2026 is incredible, easy to use and beautiful.
I find the tailwindcss approach inexcusable and unmaintainable.
How is this drastically different than a lot of software companies that open source software and then sell support service for monetization?
> killed Tailwind Labs
They are still around.
> "Give everything away for free and this people will leave technology"
This is more interesting, although somewhat generally understood (can be conflated with people seeing "free" and "cheap" and therefore undesirable). It depends on your definitely of longevity but we certainly have a LOT of free software that has, so far, lasted the test of time.
You can’t even have dynamic Classes: https://tailwindcss.com/docs/detecting-classes-in-source-fil...
> <div class="text-{{ error ? 'red' : 'green' }}-600"></div>
—- I find it really crazy that they think would be good idea. I wonder how many false positive css stuff is being added given their “trying to match classes”. So if you use random strings like bg-… will add some css. I think it’s ridiculous, but tells that people that use this can’t be very serious about it and won’t work in large projects.
—— > Using multi-cursor editing When duplication is localized to a group of elements in a single file, the easiest way to deal with it is to use multi-cursor editing to quickly select and edit the class list for each element at once
Instead of using a var and reusing, you just use multi cursors. Bad suggestions again.
—-
> If you need to reuse some styles across multiple files, the best strategy is to create a component
But on benefits says
> Your code is more portable — since both the structure and styling live in the same place, you can easily copy and paste entire chunks of UI around, even between different projects.
—-
> Making changes feels safer — adding or removing a utility class to an element only ever affects that element, so you never have to worry about accidentally breaking something another page that's using the same CSS.
CSS in js fixed this long time ago.
—-
<div class="mx-auto flex max-w-sm items-center gap-x-4 rounded-xl bg-white p-6 shadow-lg outline outline-black/5 dark:bg-slate-800 dark:shadow-none dark:-outline-offset-1 dark:outline-white/10"> <img class="size-12 shrink-0" src="/img/logo.svg" alt="ChitChat Logo" /> <div> <div class="text-xl font-medium text-black dark:text-white">ChitChat</div> <p class="text-gray-500 dark:text-gray-400">You have a new message!</p> </div> </div>
So many classes you need to learn to use it.
[dead]
> Tailwind Labs relied on a weird monetization scheme. Revenue was proportional to the pain of using the framework.
Really? To me, Tailwind seemed like the pinnacle of how anyone here would say “open source software” should function. Provide a solid, truly open source, software and make money from consulting or helping others use it and selling custom built solutions around it. The main sin of Tailwind was assuming that type of business could scale to a “large business” structure as opposed to “a single dev”-type project. By a “single dev”-type I don’t mean literally one guy, but more a very lean and non-corporate or company-like structure.
Vercel (and redislabs, mongo, etc) are different because they are in the “we can run it for you” business. Which is another “open source” model I have dabbled in for a while in my career. Thinking that the honest and ethical position is to provide open source software, then offer to host it for people who don’t want to selfhost and charge for that.
From the developer perspective not much changes despite organization structure being completely different in this comparison (trillion dollar company vs 10 individual contributors).
Tailwind Labs revenue stream was tied to documentation visit, that was the funnel. The author's argument was this revenue stream was destroyed by a slight quality of life improvement (having llms fill in css classes). Tailwind Labs benefits from: a) documentation visit b) inability to implement desired layout using the framework (and CSS being unpleasant). It seems there is a conflict of interest between the developer expecting the best possible experience and the main revenue stream. Given that a slight accidental improvement in quality of life and autonomy for users destroyed the initiative main revenue stream, it would be fair to say it doesn't just "seems like a conflict of interest". Definitely disagree with it being the "pinnacle" of how open source should function but I also won't provide any examples because it is besides the point. I will point out that fsf is fine for many decades now, and a foundation with completely different structure like zig foundation seems to be ok with a somewhat proportional revenue (orders of magnitude less influence, adoption and users, maybe 10-20x less funding)
Wasn't the tailwind team just a few people? Might be misremembering but my impression was a team under 10 people, which is tiny
Your synthesis points to software in the public interest. Governments need to start forking projects and guiding them through maturity, the same as other public utilities.
GPT is the middleman.
[dead]
The pain and opportunity will move elsewhere.
Tailwind is a handy tool that deserves support and sustainability
I think you live in a conspiracy world.
> Improving accessibility to compute power would hurt Amazon, Microsoft and Google.
Yeah, if they were not competing against each other.
> If suddenly CSS became pleasant to use, Tailwind would be in a rough spot. See the irony?
Honestly, I don't. If people suddenly adopted a heathier lifestyle, doctors, at least dentists, would be in a rough spot.
See the irony? Well, again I don't.