Comment by enkrs | Hacker News Reader

Comment by enkrs | Hacker News Reader

Parent Full thread

Maybe one point not raised enough in the eternal discussion between Tailwind vs CSS properly is the cognitive load of naming and organizing things.

To do CSS properly, you need to name classes, you need to come up with CSS cascades that work.

Being programmers we would love to categorize and name things all day long. Ever heard how we over-engineer things because of the DRY principle?

But we would love to name classes and do CSS properly only theoretically. In practice, we run out of time making CSS with nothing to show a week into the task except a CSS kitchen sink demo. By the time we're done, the scope of some component has grown in a way we did not expect and is hard to represent without markup change.

Tailwind on the other hand removes the task of thinking how to name the thing we're making. A appbutton appbutton--state-user-notallowed or a touchbutton touchbutton--disabled? In Tailwind it's just a a blue-600 rounded rectangle. Scope changed? No problem, now it's a green-400 shadow special rectangle, without checking where else it was or will be used or coming up with a new name for this special rectangle.

It's just faster. Not strictly better.

The naming of every little thing in CSS is what I call a "pseudo-problem" in the original post.

You don't have to name classes for everything inside a component. You only have to name the component, as in Tailwind. Afterwards, tag selection is totally fine. And with all the new CSS pseudo-selectors it is now easier than ever to be styling with low specifity while including markup options.

If you don’t name it then it’s sensitive to DOM changes which can look completely inert in the file in which they occur.

Have you actually used Tailwind for a week or more?

Yes I have. For a couple of years and my team still uses it.

But Tailwind is sensitive to DOM changes too, since every style is on tag. You wouldn't remove any tag without understanding its usage in a component using Tailwind. Why would you treat a CSS component any other way? If a tag's there, it must be used for something. Again, I may miss something but I see that as normal care and dilligence in both ways.

On a sidenote it's now easy to include, for example, all headings to be styled the same in a component, thereby limiting the need to adjust the CSS in case of a change of tag. There are many ways now to leave markup options opened if need be.

Your belief that you must use classes to apply CSS is false.

CSS is a generalization programming language, with specificity meant to be used for _exceptions_. Therefore, CSS should be used with general statements first, contextual statements next, utilitarian statements following, and then and only then exception-specific declaration in the edge cases they are needed.

Programming with CSS the way it was intended: Cascade, Inheritance, and then specificity, generally produces a quite DRY experience.

The one thing engineers/other programmers seem to have missed, continue to miss and seem intent on missing into the future is this: CSS is a static programming language that must account for being in and rendering dynamic contexts.

When I'm in JavaScript, I _depend_ on having the one thing, be the one thing, whenever I reach for it. I depend on immutability to keep my life sane.

When I'm in CSS, I _must_ account for flexibility, because I cannot predict the future, and I cannot predict all the various contexts in which my declaration might exist. Therefore, each CSS statement I create is based on how I would _like_ my thing to behave based upon a variety of circumstances, and to have static fallbacks when all else fails. My sanity is in producing the most responsive yet stable experience for the unknown.

Tersely, but without apology: Tailwind is for developers who do not want to take the time to learn CSS the same way they took time to learn JavaScript [or insert language of choice].

Reply on news.ycombinator.com