My team maintains around 200 websites on behalf of a design agency. Performance isn't important, and these clients aren't paying much.
Let's say a client wants to add a custom page, with some custom design.
Where do I add that? Into the global CSS, where now it needs to be maintained? Do I use a body#custom_page selector before everything? I've got elements that I now want to override only on this page. The easiest way is using inline CSS, except I can't inline responsive and pseudo-states. Updating the 5000 line CSS file with a bunch of classes under a body#custom_page selector is hard to maintain.
Tailwind solves this problem, by effectively allowing me to use inline styles even for responsive and pseudo-states, and simple variables.
CSS is effectively global state. You make a change on one bit of CSS, it can affect any part of the website, so you have to know about the whole website before making changes. And that's impossible when you maintain 100s of websites, especially when budgets are small.
I can see why Tailwind isn't helpful in a large company maintaining its own large website. But for small teams managing lots of different websites, it's fantastic. It allows you to localise and isolate the effects of CSS.
I maintain something much smaller and I'm trying to understand the various use cases, so please bear with me.
What's the problem with the #custom_page selector? If inline styles have oddities, why not keep it in separate css files, one per custom page? That would seem to precisely match the cascading style CSS is supposed to handle in the first place.
That's a lot of files if you've got 200 related-but-slightly-customized pages, but it tracks the organization of the project as a whole, no?
> What's the problem with the #custom_page selector?
This is exactly what we've done for years, but with tight deadlines, small budgets, long-running projects take on all sorts of crufty technical debt. Maybe I change a value in "special_page.css" and suddenly the homepage breaks.
Tailwind lets us isolate that cruft to where it matters.
It's not a silver bullet, but it's helped immensely. Initially, I thought it might just be "new broom syndrome", but after a year of using it, I'm still in love in a way that I haven't been since the launch of jQuery.
> Maybe I change a value in "special_page.css" and suddenly the homepage break
I'm sympathetic to this problem, having suffered through it plenty of times, but it seems like a scoping problem, and an entire library of specific functional CSS classes doesn't seem particularly well-matched to a scoping problem.
I believe everybody who says "Tailwind saved me the of work matching up CSS that was file-separated from its markup AND thinking about selector scope." And I guess this is one way to do it, but the overhead of a comprehensive property-to-class mapping seems inefficient and it's really not clear to me advantages it has over the method of the author of the article described, which also keeps markup and css in the same source file and manages scoping issues.
Yeah, the root cause is a combination of designers and sales collaborating to promise the client something out of their price bracket. If I could convince clients to pay me without that collaboration, then I'd run my own agency and be super-rich. Instead, we take on technical debt, and Tailwind lets us manage that debt more easily.
One of these days I'm gonna have to try it. Every time I read it, a lot of things strike me as Wrong (special preprocessor, obfuscated names, bypassing the "intended" way to use CSS). But so many people say "I love it and use it for everything" that it's worth investigating. (I had similar complaints about React and it's practically indispensable now.)
in a rare case where CSS actually seems to have an intent rather than throwing spaghetti at a wall to see what sticks
If the page is "special", then it simply gets a special stylesheet. I don't understand how people get so much wrong about CSS when it's really such a simple tool. My best guess is that many developers are so deeply lost in the pit of OOP that they want to apply this thinking to HTML, which just doesn't work.
You're probably right about why some people find it easier than others. As a predominantly backend dev who has to maintain frontend systems, I'm a fan of anything (such as Tailwind) that helps me do that more effectively. I'm not going to refuse to use it out of a sense of pride that I "should be able to do this in CSS myself".
Let's say a client wants to add a custom page, with some custom design.
Where do I add that? Into the global CSS, where now it needs to be maintained? Do I use a body#custom_page selector before everything? I've got elements that I now want to override only on this page. The easiest way is using inline CSS, except I can't inline responsive and pseudo-states. Updating the 5000 line CSS file with a bunch of classes under a body#custom_page selector is hard to maintain.
Tailwind solves this problem, by effectively allowing me to use inline styles even for responsive and pseudo-states, and simple variables.
CSS is effectively global state. You make a change on one bit of CSS, it can affect any part of the website, so you have to know about the whole website before making changes. And that's impossible when you maintain 100s of websites, especially when budgets are small.
I can see why Tailwind isn't helpful in a large company maintaining its own large website. But for small teams managing lots of different websites, it's fantastic. It allows you to localise and isolate the effects of CSS.