My take on this is that meaningful class names are massively helpful for maintainability and any kind of development lifecycle.
What is the name of the sub-widget you are currently building? Say you're building a card - if there is a row that has various icons for the features of the thing depicted in the card, alongside a subtitle, what is that row? It's not just an icon row, because of that subtitle. Should it be its own component? Or will you just give it a reasonable name, keep it defined inline in the larger card's component, but make it clear that you see it as a definable sub-layer? A class name is easier and less disruptive to type than creating an entire new React file for a subcomponent.
What about code review and QA? Must the reviewer read a dense string of Tailwind class names just to try to intuit what is going on? And then, when someone doing QA says "we need to add some padding on the..." - can they go into dev tools and see a reasonable name for that subcomponent? Or would they need to refer to it as the thing around the X and Y and Z, because that's the only way they have to describe the thing?
Not to mention userscripts and extensibility. For the same reasons that one might open-source parts of their stack, and for the same reason that app stores drive stickiness, allowing your users to hack on the visualization of your product can be highly synergistic. Using opaque class names takes this power away.
We've all seen Figma files with unnamed Group 142 nested in Group 134 nested in... if they are grouped at all, that is! A tradeoff was made for design speed vs. maintainability/future component extraction. Often that's the right choice at the design stage. But if you work in a realm of text editors and textual code reviews, that may not be the right choice for you.
Unfortunately like “jQuery developers” a decade ago, we now have “react developers” that don’t understand CSS and add more divs until they get the result they want.
A modal log in screen is five elements: a shade, a dialog, two labels, two inputs and a button. These are all very easy to name.
Not 300 unnamed divs. The react developer adds divs and then considers it difficult to name them all.
> A modal log in screen is five elements: a shade, a dialog, two labels, two inputs and a button. These are all very easy to name.
Agreed. But why name them at all if the structure is so simple? Keep your simple, understandable structure, colocate your styles with tailwind classes, and avoid the unnecessary cognitive overhead of naming obvious things (is it .username or .user-name?) and linking them with remote styles in a different file.
Not saying it’s the “one true way”, but I don’t think your way is necessarily simpler.
Unnamed would be great if it was just inline styles. Just not 34 class names per element in a custom DSL plus other rules to get around DSL limitations, plus additional wrapper divs because the developer does not know CSS, which is my experience of tailwind projects (including one from YC).
With all due respect, I think many of us has been massively burnt by that “meaningful classname”, that happened to be also a meaningful classname in a different part of the code, or was not specific enough, or an update to a CSS dependency broke the whole thing.
What is the name of the sub-widget you are currently building? Say you're building a card - if there is a row that has various icons for the features of the thing depicted in the card, alongside a subtitle, what is that row? It's not just an icon row, because of that subtitle. Should it be its own component? Or will you just give it a reasonable name, keep it defined inline in the larger card's component, but make it clear that you see it as a definable sub-layer? A class name is easier and less disruptive to type than creating an entire new React file for a subcomponent.
What about code review and QA? Must the reviewer read a dense string of Tailwind class names just to try to intuit what is going on? And then, when someone doing QA says "we need to add some padding on the..." - can they go into dev tools and see a reasonable name for that subcomponent? Or would they need to refer to it as the thing around the X and Y and Z, because that's the only way they have to describe the thing?
Not to mention userscripts and extensibility. For the same reasons that one might open-source parts of their stack, and for the same reason that app stores drive stickiness, allowing your users to hack on the visualization of your product can be highly synergistic. Using opaque class names takes this power away.
We've all seen Figma files with unnamed Group 142 nested in Group 134 nested in... if they are grouped at all, that is! A tradeoff was made for design speed vs. maintainability/future component extraction. Often that's the right choice at the design stage. But if you work in a realm of text editors and textual code reviews, that may not be the right choice for you.