I think CSS at scale is an interesting problem to reason about.
It's the "at scale" thinking that right now puts "Option 1: Just write the CSS" at a huge disadvantage. That's a problem because it encourages people to never explore the fundamentals to any sufficient depth and go straight for the derivative solutions.
(The fact that even knowing CSS in depth doesn't convey any insights about effective layout and design is an entirely separate discussion.)
To scale, the contemporary solution of choice is "to componentize" which is an extension of Class-based Object Oriented thinking in software development in pursuit of elusive reuse opportunities.
As evidenced by the popularity of Single File Components many people hold the belief that styling is part of a component.
This overlooks an important insight from OOCSS: separate structure and skin—the structure is part of the component, the skin is not—so there are fundamentally two distinct concerns being addressed by CSS.
Now I'm a total layperson when it comes to visual design as it pertains to web design. But upon exploring ITCSS I got the distinct impression that visual design isn't a bottom-up affair like component development typically is but a top-down discipline where the whole sets the stage for all the parts to work together (hence design system)—which would certainly explain why CSS works the way it does.
DaFED#27Managing CSS at scale is hard; and a lot harder than it should be. ITCSS is a simple, effective, and as-yet unpublished methodology to help manage, m...
youtube.com
So in my judgement "enterprise CSS" is attempting to coerce the concern of styling into the mold of componentized software development—which may not be a great fit. While it is clear that large scale CSS needs to be organized in some way (to support a design system) it is not clear to me that components should be the dominant concern. Components (blocks really) certainly have a role to play but are only one aspect of the overall design.
From that perspective I find options 2 and 3 way too tightly coupled to the component organization compared to other possible options.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's the "at scale" thinking that right now puts "Option 1: Just write the CSS" at a huge disadvantage. That's a problem because it encourages people to never explore the fundamentals to any sufficient depth and go straight for the derivative solutions.
(The fact that even knowing CSS in depth doesn't convey any insights about effective layout and design is an entirely separate discussion.)
To scale, the contemporary solution of choice is "to componentize" which is an extension of Class-based Object Oriented thinking in software development in pursuit of elusive reuse opportunities.
As evidenced by the popularity of Single File Components many people hold the belief that styling is part of a component.
This overlooks an important insight from OOCSS: separate structure and skin—the structure is part of the component, the skin is not—so there are fundamentally two distinct concerns being addressed by CSS.
Now I'm a total layperson when it comes to visual design as it pertains to web design. But upon exploring ITCSS I got the distinct impression that visual design isn't a bottom-up affair like component development typically is but a top-down discipline where the whole sets the stage for all the parts to work together (hence design system)—which would certainly explain why CSS works the way it does.
Harry Roberts - Managing CSS Projects with ITCSS - YouTube
DaFED#27Managing CSS at scale is hard; and a lot harder than it should be. ITCSS is a simple, effective, and as-yet unpublished methodology to help manage, m...
So in my judgement "enterprise CSS" is attempting to coerce the concern of styling into the mold of componentized software development—which may not be a great fit. While it is clear that large scale CSS needs to be organized in some way (to support a design system) it is not clear to me that components should be the dominant concern. Components (blocks really) certainly have a role to play but are only one aspect of the overall design.
From that perspective I find options 2 and 3 way too tightly coupled to the component organization compared to other possible options.