I personally have an issue with this "Utility/Functional" CSS pattern.
To me I still think that the good old "HTML describe how the content is organized, CSS describe how this content looks like" is the way to go. In the end it's how CSS and HTML were designed at first.
Isn't that basically the same thing as inline styles?
Not quite, for a few reasons:
Inline styles don't respect media queries, which basically rules out responsive design
Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue)
Inline styles cause specificity issues, since they trump separate stylesheets.
Inline styles don't support print-specific styles.
Inline styles can't address pseudo-elements (such as ::before and ::after)
Inline styles can't apply to multiple elements. Utility classes can define .bg-blue once and have it apply to many things, which leads to shorter markup and quicker rendering speed.
Inline styles are a pain to type. Compare class="f-sm bg-blue" to style="font-size: 10px; background-color: #0000ff;".
Ok maybe I was too negative too quickly, sorry. After reading another article [1] linked in some other comment I can see the appeal, if used with some templating engine that allows reusing html (like Vue or React).
It is crazy how new technology brings up old patterns again. Similar to how it was frowned upon to have JS near your HTML ("must be separated!") and now with React they are intertwined to a maximum.
I oftentimes find css to be the most complex and hardest to change part of web applications and am thankful to any approach that explores alternatives!
There seems to be a misconception that you need to go all-in on utilities when using a framework like Tailwind.
If you have 500 buttons using the exact same set of classes, you should of had a button class in the first place. Almost all my projects have their own button and form input classes for this exact reason!
Where utility-based CSS frameworks really start to shine is the other 75% of your codebase, where you're inventing clever class names, only to end up using them once.
This is also why Tailwind calls itself a utility-FIRST framework. Build things with utilities, and extract components to classes when the need arises. Avoiding early abstractions provides a lot of value (in any programming language for that matter). Not having to invent a name for every single piece of UI also saves a ton of headaches down the road.
In my experience design revamps of this magnitude has always needed fresh markup, CSS, Javascript - aka an entirely new front-end. But in case it is just the color of all buttons, then you'd change them in the components. 700 components is quite a stretch - for example there are at most 50 components in Morning Star's design system - http://designsystem.morningstar.com/.
But let's say there are 700 components, what's the alternative if we were using BEM? You'd have to change all the 700 CSS classes, breaking things everywhere thanks to cascades, inheritance, multiple selectors, and specificity. With Functional CSS, all you have to do is go to the markup, and change "bg-white" to "bg-offgrey", and nothing breaks.
In my (limited) experience when I'm repeating the same set of classes over and over again I extract to a named component; You shouldn't have 700 identical buttons that all specify the classes that compose their look. 5-7 times = a use pattern and time to extract it.
In tailwind, you have a config file. You can just change the variable in the config file to the colour you need to change it to and it changes globally.
That’s incorrect. What your missing is that in the config file you define a new color; say ‘rose’ and then the framework auto provides bg-rose, text-rose, border-rose, cutting duplication and bringing consistency.
I think the big shift started to happen when people started to say, let’s treat CSS like code and what would we expect of good code, and then all of these CSS Sacred Cows were then seen in a new light. The biggest of them all for me was ‘naming things are hard’, traditional CSS implies naming your classes is easy, and for a once off example it is always easy, but that approach is a lifetime commmitmnet to generating names on names just to add styles and this adds a naming things complexity burden that until recently has just been a generally unacknowleged invisible cost.
In the post you mention extending the first class, author-bio, to the article class. When you introduced the idea of the media-card wouldn't it make sense to have both the author-bio and article classes extend from it, maintaining the semantic naming but also making it easy to override or change some style for one in particular?
Overrides are special cases. Usually you start with one, but before you know the CSS file has bloated to thousands of lines with hundreds of overrides depending on context. With enough of them you can't comprehend the CSS anymore, which means you can't change any existing classes, and so the CSS becomes write-only.
To me I still think that the good old "HTML describe how the content is organized, CSS describe how this content looks like" is the way to go. In the end it's how CSS and HTML were designed at first.
But when I see that
I'm sorry but it just doesn't feels right to me.