Serious question: is there a need to reach for tailwind if you are building a new site? Won't using vanilla CSS while taking advantage of the latest features be pretty good, since humans are not manually making edits (which removes many of the pain points of maintaining CSS), while simplifying dependency and the build pipeline?

Yeah, Tailwind is great as long as you have some way to reuse markup, like React. You don't have to care about class names and whether CSS defined somewhere else affects styles of a current component at all. That last point makes sense for LLMs as well: all the styles that affect the current file are automatically in context since styling is local. Admittedly, there are other ways to achieve this but the ergonomics of Tailwind are just good. Having nice defaults and good training data is an added bonus.

In my experience, if you're going to aggressively componentize whatever you're building (i.e. a button isn't a css class on a simple `a` tag but a distinct component that exists in it's own file somewhere) there's huge advantages to having your styling be associated directly with your components, and Tailwind is a great option (among many) for that.

If you're building something where your unit of organization looks more like a "page" than super fine grained elements, Tailwind will just make things messy and a higher-level library or writing your own CSS would be a better approach.

I don't think this changes much with AI - right now most models are not terrific at maintaining a huge degree of context in larger projects, so I could absolutely see an agent implementing CSS that works well in isolation but breaks due to the cascade. Maybe that changes in the future, but right now if anything I think Tailwind is well suited to AI because it enforces a certain locality to the changes you're making (i.e. you can reasonably assume that a `text-red-500` class on an element isn't going to break things elsewhere and wll do what it says on the box).

IMO, Tailwind is just inline CSS with standardised defaults. I think it found its place because most React devs didn't want to bother with CSS

Vanilla CSS can take advantage of features like that "cascading" part that Tailwind goes entirely against.

If you are styling a site, there's no competition at all. But if you are styling a single interaction-heavy page, it's a lot less work to put all the formatting inline instead of thinking about a descriptive structure and write your CSS around it.

Apparently a lot of people design entire sites one page at a time.

LLMs seem to work well with tailwind which I assume is because there was a lot of tailwind in the training data. As a human I never found tailwind to be particularly easy to work with anyway (mostly because I can't be bothered to learn another CSS framework) so I was constantly checking the docs when manually writing code. But I do like the rigidity it forces, which is probably a good thing for AI coding as well.

I only do front-end dev occasionally, but these are my 3 goto articles that make me lean towards not using Tailwind:

1: https://www.zolkos.com/2025/12/03/vanilla-css-is-all-you-nee...

2: https://www.joshwcomeau.com/css/subgrid/

3: https://railsdesigner.com/custom-elements/ (more Rails specific)

Believe me, I try all the time. But HTML and CSS are not made for the modern web.

Styling radio buttons, working date inputs, forms that POST automatically, typeahead and server-side validation (eg username already taken.)

You spend all your time reinventing the wheel and then it's buggy and looks like a dog. To say nothing of the inevitable poly fills and Cross-Browser issues.

What's "funny" is that newer/modern CSS is often very clunky to write in Tailwind, or unsupported entirely unless you build your own selectors, but AI doesn't understand those well or how broad their support is, so getting AI to write good/modern CSS outside of Tailwind is pretty difficult. I suppose someone could make a new library that is for AI tools that focuses on the latest and greatest in CSS, but there's no market for it any more because AI would just steal it and generate UIs with it.

This is a good discussion: do LLMs change the calculus for DRY?

A major point of components is having a single place where you can change design and behavior across your entire codebase. With LLMs you can with very good accuracy tell them to change the look of "all buttons that are confirmation buttons in modals but not in the login modal". Doesn't matter if there are 10 such buttons or 1000, it'll take a few seconds for them to accomplish it.

I'm slowly forming the opinion that nowadays having copy-and-pasted "components", with their whole HTML just repeated over and over, is now a much less worrying thing in a codebase. Even a bloated CSS can be quickly fixed by a LLM.

And like you said: you eliminate the build phase entirely and frontend development ergonomics goes back to how it was in the early 2000s.

Personally I still find it really helpful to have a proven framework to rely on so that I can be confident I'll have a reasonably consistent looking UI across a range of browsers, browser versions, screen sizes, and OS even versions.

is there a need to reach for compiled languages if you are building a new program? Won't using vanilla assembly while taking advantage of the latest instructions be pretty good, since humans are not manually making edits (which removes many of the pain points of maintaining assembly), while simplifying dependency and the build pipeline?

(Abstractions are still very useful to LLMs)

Not at all, I personally never used nor plan to.

I am a big advocate of classes, not inline styles spaghetti.

The only contact I had with it was due to FE teams jumping into it, however every couple of months is something else anyway.

Imo no

CSS is really good these days. Scope rules and the new selectors available mean you actually have to work hard to mess things up like you did in previous eras

Writing CSS in a way that will scale up with the size of your project and team is just as hard as it's ever been, you still have to come up with a convention for doing that, including taking into account what newer features bring to the table. Having to manually edit it was never the pain point.

Short answer: no, not necessary. Long answer: https://mastrojs.github.io/blog/2025-11-27-why-not-just-use-...

As someone that hates Tailwind, I think there is actually a use case here. If you are fluent in CSS reaching for Tailwind is probably a mistake. But for better or for worse there are lots of developers who can write HTML and JavaScript (or more likely React) who will not, and do not want to, learn CSS, for them things like Tailwind is a godsent.

I do think Tailwind is overused, but it obviously has some legitimate use case.

There’s been a lot of devs reaching for StyleX over Tailwind recently. Not sure if hype or there’s real advantages.

Tailwind is still considerably easier to work with than vanilla CSS. You just have to write less.

A few of my teams use tailwind. As someone who used css directly for years, this just means I have to waste time looking up the tailwind equivalent of things I know (if I’m not vibecoding). Strongly dislike it for that. But css management is really bad without it too. If I knew all the tailwindisms, it would probably be a clear winner.

Don't do a lot of technical work nowadays, but tailwind is still my go-to. Vanilla CSS just doesn't have nice ergonomics.

With AI I guess you could skip it, but I like to understand the code.

It still helps deduplicate.

there's never a need to reach for tailwind, it's just a pathology some people like because someone else did the design work for them

[dead]

I quite like Tailwind. I've had great experiences with it, especially on projects where the skill level of contributors was highly variable.

That said, Tailwind is not as powerful as plain old CSS. It's a bit like training wheels for CSS—you gain some guardrails and prevent newbies from messing things up too badly, but you also give up the power modern CSS affords you.

E.g. I invite you to look at some of Ahmed Shadeed's (https://ishadeed.com) layout tutorials, or whatever you find on the CSS-Tricks/Masters.dev homepage today. It's bonkers what you can do with modern CSS!

Tailwind gives you access some of what's possible with CSS today, and they keep adding support for new features, but it's impossible to express everything CSS is capable of using only utility classes. At some point, you need to write some actual real CSS code.

So personally, it's a tradeoff for me. If I really want the full power of CSS, I use plain old CSS. If I'm willing to trade power for the convenience of Tailwind's built-in design tokens and guardrails, then I pick Tailwind.

Both approaches are good and valid. The right choice is context dependent. With And with LLMs in the mix, it's not that hard to port a Tailwind codebase to plain CSS, or vice versa, so picking the wrong thing doesn't have as high a cost as it used to.