In defense of functional CSS

When the customer asks me to change the background of primary buttons from green to yellow and the background of nonprimary buttons to red, while changing other green backgrounds to a green-brown gradient, classes like "Button Button__Primary" tell me much more than classes like "bg-green".

Even if you only have one client - do you really want to manually hunt down all profile-card instances and update the styling anytime you need to change the styling?

And if you had a bug related to profile-card styling, are you going to find all cards to update the styling? Are you sure you didn't forget some?

This approach seems to be based on the idea that design is completely immutable after the initial conception. This is... not how design usually works :)

The benefits?

> You don't have to write any CSS of your own (which, to me, is fantastic)

This applies to any CSS or UI framework.

> You can likely build things faster (obviously non-scientific, but anecdotally I've seen many people confirm this)

Yes, this is anecdotal and debatable. At the end of the day, you still have to read the documentation of this specific CSS framework.

> You don't ever have to think about naming things

I don't think developers that are creating anything don't ever have to think about naming things. If you're creating something, you have to name it. But yes, you don't have to add that name to your CSS class.

> You can tell what something looks like by just reading the markup for it

You could also tell what something looks like by just reading the CSS for it.

> You don't ever have to worry that changing the styles for one thing will break something else (which may make visual regression testing irrelevant)

There's a couple other approaches to this like style localization/isolation that the author called "ton of crazy randomly-generated class names". As opposed to the ton of single-purpose utility class names, which is more sane? You could also write stricter CSS selectors (like BEM or your own).

> You never have to deal with one instance of a thing needing a slightly different style than the other instances, which screws up your reusable classes.

Sure, as long as if you stick to a framework. If you're building a one-off with no collaboration with other people, then this is easier to pull off with an off-the-shelf CSS/UI framework.

> Your CSS always stays the same size rather than expanding over time

Okay!

> It's easy to un-apply a style by just removing the class (as opposed to the traditional cascade where you typically have to override, adding even more CSS)

You could isolate styles that are prone to removal into a single class with regular CSS too. Hate to be the nerd to say this, but the "Cascade" in CSS is what makes it such a versatile interface styling engine.

> Rendering speed performance is supposedly improved (though I have seen no proof of this)

Once again, anecdotal.

————

Sounds like the author is allergic to reading/writing CSS and wants the markup to be heavily coupled with styling. Also sounds like having a strict framework makes their developer experience happy, which is applicable to any well-designed design system.

There's nothing wrong with any specific CSS methodology or framework, and there's a time and place for every single one of them.

I think I would prefer vanilla CSS with strict rules for one-offs before using something like this, though.

I've found this is (usually) solved with soft skills. I just talk to the designer and explain we have all these very similar components already and it will help with the visual consistency if we follow an existing convention OR update the existing convention to use the new style (giving them the option to choose let's them stay in control of the design). They are usually very understanding as they don't always consider these things.

variables and mixins, clean css, readable templates instead of some overloaded hodgepodge of classes.