While I can appreciate the simplicity and directness of this approach, it misses a fundamental aspect of CSS and HTML that many people miss - it's about semantics, about creating a domain specific language that clearly expresses the intent of the styling and markup. For example, it might be appropriate in an application to style buttons two different ways - rather than implement two different buttons each with their own set of paddings, margins, etc., etc., we implement two CSS classes with a name that clearly expresses the intended use - primary, navigation, etc.
There is also a good point in Sean's tweet in the previous comments about building with utilities and refactoring emerging patterns - definitely sage advice, but I feel there is a parallel with TDD here. Do your UI/UX design first and then make your acceptance tests pass - a skilled designer will know the common design patterns and guidelines (e.g. Google's Material Design) and be able to incorporate them into a design language for the application, without needing to refactor them out later.
Yeh, true, components do give you another way of encapsulating styling - the whole "CSS in JS" thing. There isn't a right or a wrong way, or even better or worse, just pros and cons. I'm one of these strange people who actually kinda likes CSS despite its quirks and thinks it's fit for purpose, so I'll always advocate using it semantically, but each to their own! Good food for thought anyway.
While I can appreciate the simplicity and directness of this approach, it misses a fundamental aspect of CSS and HTML that many people miss - it's about semantics, about creating a domain specific language that clearly expresses the intent of the styling and markup. For example, it might be appropriate in an application to style buttons two different ways - rather than implement two different buttons each with their own set of paddings, margins, etc., etc., we implement two CSS classes with a name that clearly expresses the intended use -
primary,navigation, etc.There is also a good point in Sean's tweet in the previous comments about building with utilities and refactoring emerging patterns - definitely sage advice, but I feel there is a parallel with TDD here. Do your UI/UX design first and then make your acceptance tests pass - a skilled designer will know the common design patterns and guidelines (e.g. Google's Material Design) and be able to incorporate them into a design language for the application, without needing to refactor them out later.
All works in theory, anyway :)
You can still create vue/react/... components for each thing you want to represent. That way, modifiers (size, color etc.) simply become props.
Yeh, true, components do give you another way of encapsulating styling - the whole "CSS in JS" thing. There isn't a right or a wrong way, or even better or worse, just pros and cons. I'm one of these strange people who actually kinda likes CSS despite its quirks and thinks it's fit for purpose, so I'll always advocate using it semantically, but each to their own! Good food for thought anyway.
@apply?