It's not about DRY. It's about modeling. It's about design. It's about being able to look at markup (as a human) and tell what the heck it is. Tailwind soup obscures what things are. How many of your Tailwind-using apps ALSO have meaningful class names and IDs in your markup? How many of you rely on data-test-id or other such hacks to make up for the fact that you are not doing design.

Classes are used to categorize the markup. It's a document model. Model the document. Then, you apply styles to that. It's about design.

> It's a document model. Model the document.

I think this may be the source of many religious wars in frontend land. HTML was originally a document model, but now it does dual duty as a way to block off rectangular sections of application UI.

The purist approach of writing perfectly semantic HTML and placing all presentation in optional, layered style sheets works beautifully - for documents. But I don’t think it works as well when you are designing an interactive UI and you’re really just trying to manipulate pixels on a screen.

Tailwind sure is ugly, but it’s quick to write and a cinch to debug. And in my experience, most UI code is pretty ugly. It seems to come with the territory?

I've also made this argument, but I was wrong. It turns out it's also possible to model a UI. And, it's possible to do that relatively well with HTML. You can see web components or React for contemporary examples of doing this (though no guarantee that the example you look at will be doing it well).

It stands to reason that if it can't be done with HTML, then it can't be done with React, or Swift UI, or anything and we are all doomed. Of course, that's not true.

> Tailwind sure is ugly, but it’s quick to write and a cinch to debug. And in my experience, most UI code is pretty ugly. It seems to come with the territory?

UI code doesn't need to be ugly. It may come with the territory for most teams, but it doesn't need to be that way. We don't need to be working in giant monoliths that take an hour to deploy and run tests either, yet many teams are. We don't need to live in squalor, but when it's all we've known, we become accustomed to it. We give TED talks telling people how great it is to live in squalor and about the "one weird trick" that makes it a little more palatable.

The only "trick" we need is design. I'm not saying it's easy (in that it is readily available and applicable knowledge for the average developer), but it is attainable.

Don't you find when developing web apps that you often need to use elements that have no semantic value? I'm referring to divs that are needed as hooks/exploits/workarounds for CSS, such as redundant containers that have (or don't have) relative position, or are needed for their stacking context, or to contain overscroll, or to prevent a shadow from being clipped, etc.? These problems also grow more complex when you have to compensate for Safari's issues. I always try to abuse ::before and ::after to streamline the markup, but there's a lot these pseudo-elements can't do.

I wouldn't say it's often anymore, but it happens. It comes with the territory. We can sometimes avoid giving them class names by targeting them with things like immediate child selectors. We do end up with mechanical class names from time to time. But that doesn't mean we throw in the towel on modeling entirely.

I concur. A lot of frontend problems wouldn't exist if HTML had something like XSLT. The fact there's no non-javascript way to reuse HTML code is a already a failure of DRY. Pretty much every web 2.0 technique so far has been just us trying to add DRY to a language that doesn't support it.

> How many of your Tailwind-using apps ALSO have meaningful class names and IDs in your markup?

The markup doesn't need meaningful class names because CSS is encapsulated in reusable HTML fragments that have meaningful names. Your approach to structuring markup is simply unnecessarily more repetitive.

Poorly defined "design" principles have a cost, and where they conflict with concrete principles with a proven track record, like "reusable abstractions", then the poorly defined principles are wrong.

> The markup doesn't need meaningful class names because CSS is encapsulated in reusable HTML fragments that have meaningful names.

They have meaningful names... where? In React (or whatever). They don't in the web inspector (so just use the React dev tools! Yes, more complexity). They don't for testing tools like playwright, cypress, or capybara (so just use data-test-id! Yes, now you have to name something FOR TESTING PURPOSES ONLY, which is a clear sign of failure).

> Poorly defined "design" principles have a cost, and where they conflict with concrete principles with a proven track record, like "reusable abstractions", then the poorly defined principles are wrong.

I'm not sure that attempting to redefine design into something that you can ignore will do you much good, in the long run. If you think that "reusable abstractions" are a problem, then it's highly unlikely that there is a fraction of a square inch of common ground between us and any further conversation will just lead to frustration.

> They have meaningful names... where? In React (or whatever). They don't in the web inspector (so just use the React dev tools! Yes, more complexity).

They have meaningful names in the locations where people actually need to care about meaningful names: in the template language or the component model used to generate the final markup. If you're suggesting that class names should be meaningful for people who want to read the generated markup and they can only make sense of it because of class names, you're penalizing all front-end development for an absurdly small niche.

If you need identifiable names for testing purposes, that's what other queryable HTML attributes are for (id and name in particular). In your template language you already have the component name available, so just assign a queryable attribute using that where necessary. Nothing wrong with that.