Working with Tailwind CSS every day for 2 years

You manage this complexity the same way you manage the complexity of repeated code nearly anywhere else: you encapsulate. If you have a standard box (div + styles) that you use everywhere, abstract it in whatever way you're writing your application allows. For example, a component in React.

Wow thanks for this as it's not at all mentioned in the help text for these (Configure editor settings to be overridden for a language.). Also what a strange choice for multiple languages since there can clearly be conflicts this way:

    "[javascript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[typescript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[javascript][typescript]": {
        "editor.defaultFormatter": "something.else"
    }

If they're going to allow conflicts anyways, just invert the structure so you at least get to use normal arrays:

    "editor.defaultFormatter": {
        "esbenp.prettier-vscode": ["typescript", "javascript"]
    }

Though, I guess the logic is that the other format allows you to override ANY setting based on language.

I'm in the same boat, and Tailwind looks like something that would get in my way (or at least becoming annoying very quickly.) I don't want the equivalent of inline styles all over the place.

> This is so frustrating to read over and over. Tailwind uses PostCSS. You can literally wrap a bunch of utilities inside a semantic class name.

If it's being asked repeatedly, it should probably be addressed somewhere. I see no mention of it in the tutorial or any of the amazing starter videos I've seen. I also have never used PostCSS directly before, so that's not an obvious solution. I appreciate the example you shared. I've asked (the OP in particular) in good faith, so I'm sorry that the question frustrated you.

> Personally, I've always found BEM to be tedious and the sort of "roll your own" class names just doesn't scale. This approach scales. This is what we should be moving towards as an industry.

Can you please elaborate on this? We've had well-functioning applications that predate Tailwind or CSS in JSS, so I'm not sure what doesn't scale. Descriptive names might get messy if you jam everything into in a single stylesheet, but using the cascading part works pretty well. If we're going to say "no, actually we were completely wrong when we said class names based on styles like 'red', 'big', and '2spaces' were bad", I'd like to understand what fundamentally changed. If it's just a case of convenience, that's fine. But, what about this scales better? How does this approach improve maintenance?

Your PostCSS example where you compose rules looks like a good approach, but I don't see that widely in use. Instead, I see the same rules repeated across elements in a document. That's the style the Tailwind docs use, so I'm operating under the notion that this is the prevailing way to write frontend code with Tailwind. While I can see that as an improvement over inline styles by ensuring consistent spacing definitions and such, that was never the recommended approach anyway. The style used in the Tailwind docs strikes me as being more problematic for ensuring consistency across pages or an app, which I see as hampering scalability.

Anyway, I'm trying to better understand why and how this shift is better. The only clear answer I've had thus far is that it's faster to get started because you get nice styles out of the box without having to adopt something like Bootstrap. That makes sense to me for small projects. At least I can see why someone would make that trade-off. I'm less clear on the long-term maintenance aspect and how utility classes help that.

> A lot of people I respect really like Tailwind, but I just don’t get it.

I think I get it. For years there have been lots of popular CSS authoring conventions for JavaScript apps that are clever but complicated, fragile, and have a lot of churn. Most of these either have large JavaScript runtimes that generate and inject styles on the fly as components render, or deep integration into the JavaScript build system like Webpack/Babel/etc. plugins, or both.

I believe that there was intense fatigue from supporting these systems, keeping up with the newest versions and trends in the high-churn JavaScript ecosystem, etc. Tailwind essentially offers a ridiculously simple way out of this fatigue. You just say screw it, let's just author all our JS component styles using string literals that from JavaScript's perspective are just totally arbitrary HTML classes. No more importing things, or using plugins that transform the AST of our JS source code, or extracting chunks during SSR, etc. We just run this totally separate Tailwind compiler that looks for string literals that seem like Tailwind utility classes and generates a stylesheet that we just import in our HTML.

Tailwind is pretty great on its own as a utility CSS framework. There's a lot of thought put into the "API" of their utility classes, and because it's so popular there is a ton of support for almost any use case you'll come across. But at the end of the day, I think the reason for its ubiquity (particularly among respected veterans and "influencers" in the frontend community) is that is offers a way out of the "JavaScript tooling rat race" that was causing so much fatigue.