Comment by Klonoar
2 days ago
Counter-argument: the cascade in CSS was a massive design mistake and it shows even more in this particular case.
With LLM-assisted development you spend more time reading and reviewing the generated code. The cascade in styles is nowhere near as readily apparent as something like Tailwind.
I haven't seen cascades be a problem since the days of monolithic, app-wide stylesheets, and no project I personally know of works that way anymore.
Just about everyone uses component-specific styles with a limited set of selectors where there are very few collisions per property, and pretty clear specificity winners when there are.
If the alternative to the cascade is that you have to repeat granular style choices on every single element, I'll take the cascade every time.
> Just about everyone uses component-specific styles
Yeah.
At which point you can simply use e.g Tailwind.
What component-specific styles look like:
class="menu-item"
Styles-in-HTML (Tailwind):
class="m-4 mb-2 p-2 border border-radius-sm border gray-200 hover:border-gray-300 font-sm sm:font-xs [...]"
You can be completely insensitive to or unbothered by the difference, but that doesn't mean they're equivalent.
1 reply →
No, because many components have internals that need to be styled consistently with parts of other components.
With plain CSS components can easily share styles and use them by adding the correct class name to elements.
With Tailwind you have to copy your list of super fine-grained classes to each component, and try to keep them in sync over time
If you're arguing down that route, LLMs can bulk-apply style attributes exactly where they're needed. Every element precisely described, no need for CSS and style-sheets at all.
And then you'd wind up with a needlessly noisy approach, and then you will reach for Tailwind to do basically the same thing but in a more terse manner. ;P