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 @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.