[plainOldText]

I had always avoided using any CSS frameworks because I wanted to master and also maintain complete control over my CSS, but after having used Tailwind for a few projects now, I don't think I would every want to go back to writing raw css ever again.

[andrewflnr]

My best guess is, you get your DRY properties by re-using app-specific components that use utility classes, rather than by re-using app-specific CSS classes?

Trying to figure out why people think it's a good idea. It's certainly not the vision of web dev I was trained on.

[CSSer]

If I can chime in here, yeah that’s the gist although I’ll say Tailwind isn’t a panacea. My team and I still write vanilla CSS, but it’s less common and much more navigable. It’s usually because the Tailwind version (if the utilities exist) would be unwieldy.

When I started writing CSS I would commonly encounter modestly sized websites of only a couple hundred pages with 17 thousand lines of CSS or more because of frameworks like Bootstrap. At least a few hundred of those lines would be overrides and just as many would probably be redundant.

My team launched a 6 thousand page website this past year with only a couple hundred lines of vanilla CSS and roughly 3 thousand lines of Tailwind generated CSS total.

At the end of the day, Tailwind is a zero-runtime, tree-shakable CSS framework generator. The burden of naming many common and universal design artifacts is alleviated. Class reusability goes through the roof. Custom stylesheets regain the ability to be edited with confidence again. It’s good. It makes the HTML a bit bloated and ugly which deters people at first, but dev tools pick up the slack and so far I’ve yet to see any performance impact there.

[Scarbutt]

How many of those 6k pages use the same CSS?

[pcthrowaway]

Not the person you replied to, but the answer is: all of them

That's just how tailwind works.

[CSSer]

pcthrowaway is more or less right. Tailwind dramatically improves code coverage. A majority of tailwind's common utilities are used in every page's components or templates.

There are exceptions. We could use postCSS to code-split critical paths for CSS. It sounds like a fun side project for some framework's ecosystem. Unfortunately, the current state of CSS is very much good enough for me for now. I'm much more concerned about main thread work from JavaScript and optimizing images for the web, for example.

[Rodeoclash]

Two things you must keep in mind with Tailwind that are key to its success, they are:

1. It gives you bunch of sane defaults around colours and spacing. If you consistently use Tailwinds classes then you'll get a nice grid and (usually) complimentary colours.

2. You're using a a framework or view library that supports reusable components. For React, this is obvious. For Phoenix, you use LiveView components or the Phoenix "static" components.

Tailwind only really works when you apply its classes to components, then reuse the components (or more tersely: "Reusable styles via reusable components")

[sbergot]

Here is an important article about functional css (tailwind's model) vs semantic css (what you have learned): https://adamwathan.me/css-utility-classes-and-separation-of-.... You might disagree with it but at least it provides the reasoning behind tailwind.

[andrewflnr]

I think I read that a while back, which is the main reason I'm able to get past the "visceral reaction" as he so aptly put it. The part about separation of concerns being a false hope and bad framing rings true: "concerns" in software are hazily defined at the best of times. Thinking about dependency between CSS and HTML also makes sense. But I don't really like his examples, and I'm not convinced his evidence reaches quite as far as his final conclusion. For one thing ".author-bio" should have been "#author-bio".

Thinking out loud, now: the problem of CSS and HTML depending on each other makes me think of the dependency inversion principle. Basically, make both of them depend on some common interface or protocol, so they can change independently. Utility classes are in the same territory, but I don't think it's reasonable to demand that the shared language be app-independent, or put another way, to demand that a library author relieve you of the burden of naming your domain objects.

I suspect the ideal approach is app-specific "content-agnostic" classes, defined in terms of some library of helpful classes that are not themselves directly invoked in HTML, with #ids as needed for specialization. But I don't know, maybe I'll just try to the tailwind thing out on a new project.

[plainOldText]

For me Tailwind is an elegant and powerful design language, one which has sane defaults, and which gives me the opportunity to experiment quickly and instill life in the structure of my html right there where I type it, with just a few keystrokes and no change in context.

[peferron]

CSS isn't special; HTML and JS have similar needs for reuse and customization. It doesn't make a lot of sense to have a completely separate solution that solves this problem for CSS only.