One big drawback of Tailwind I never hear anybody talk about: it makes things all but un-targetable by other CSS.

Say I just used regular CSS. And say, eventually, I need to turn all the section subheads on a page green.

Easy. Just use the `.subhead` class you already wrote to add an override. Done.

In a pure Tailwind world, that doesn't happen. You literally have to edit every single component you already built, because not one of those utility classes is actually unique to those subheads.

Please don't "you can use classes in Tailwind too" me. I know. Thing is: you don't do that if you're using Tailwind. It's built so that's cutting against the grain, at best, and actually just doing the same thing as normal CSS but with more complexity at worst.
@collinsworth Exactly. If you don't have a robust CSS architecture at the start of a project, you can't suddenly start bolting on bits and pieces later alongside Tailwind. That's a recipe for disaster!
@jaredwhite @collinsworth strong agree (having just had to un-tailwind an app).
@developit @collinsworth Cool! I'm on a team right now that's unTailwinding a bunch of our components…thankfully a little bit easier since we were already using companion CSS files and @ apply for a lot of it, so now we're just transitioning everything to vanilla (plus a dash of Sass) along with custom properties for design tokens. ☺️
@jaredwhite @collinsworth on the plus side, it really makes you realize how amazing pseudos and media queries are.
@jaredwhite @developit @collinsworth we’ve done the same, though without custom properties. We just use sass variables. What do custom properties buy you in your experience?
@aaronjensen @jaredwhite @collinsworth dynamic themes and the nicety of not needing to preprocess your CSS (at the expense of not having access to cool things like color mixing).
@developit @jaredwhite @collinsworth Thanks. We also use mixins and custom functions. Somewhat sparingly, but it allows us to create abstractions and remove essential duplication.
@aaronjensen @developit @collinsworth Well, in our case we have the perhaps somewhat unusual requirement that the main app can actually be soft forked by a third-party, yet still use a common design system, so our components all need to be really easy to theme. This way, somebody can set up an app override stylesheet and very easily tweak a few custom properties (our "styling API" / design tokens) and instantly see the re-skin in action. It's pretty cool!
@jaredwhite @developit @collinsworth That makes perfect sense. That sounds like a great use of them.

@collinsworth this was one of the main reasons I stopped using it. When I wanted to do even the most basic things ("remove top border from first item in list", "give posts a slightly smaller font size in modals", etc), the only viable option was to add a bunch of super specific styling props to my components.

This is a dealbreaker for me, because it means I'm writing JavaScript to work around limitations in the styling system. CSS is nearly free, JavaScript is hella-not.

@collinsworth I argued multiple times it leads to maintainability hell but then just got a lot of hate back.
@wolfr @collinsworth Clearly you're just holding it wrong. 😜

@collinsworth they manage that complexity in javascript

lol jk it's just three different greens on about 80% of subheads, the remaining 20% are the old color or a deeply inherited mystery color.