In defense of functional CSS

It really isn't. I'd say in some cases it's the opposite.

At my job, we have a mid-size React app where more or less every element has one CSS class with all the styling in it. There used to be more of a framework of reusable styles, but it doesn't get used much any more because it's out of date with what our designers want now. We should fix it, but there's no time because we have to pile on more features to fix later. You know the drill, I'm sure.

But basically, for more or less every HTML tag, there's a custom blob of CSS that's only applied once. This is inline styles, we've just moved them to a different set of files.

>When you want it to have a different (standard) margin, use a utility class on it.

Then when the next PM wants this button to be blue, you make another utility class and end up editing HTML. It's better to just think entirely in terms of components that are independent of any external framework or guideline, which are only responsible for themselves. Everything on your page is a concrete implementation of an abstract component, and in that implementation you can customize all you want. Otherwise you end up with a massive dependency graph between components of various "utility classes" rather than a completely flat hierarchy of components which handle their own dependencies.

In the old days, I was doing CSS by hand for every site I made. It kind of sucked.

Then Bootstrap came out, and the idea of CSS frameworks was a thing. I loved Bootstrap, but so did a lot of other people, and as a result you started seeing Bootstrap everywhere...like when you buy a car and you start seeing everyone else driving one where ever you go.

So I started trying to customize Bootstrap to make it look less like other bootstrap sites by adding custom CSS, which basically brought me back to where I started.

In practice it has been much, MUCH easier to work with CSS frameworks that use utility classes, because it makes customization easier. I do think there needs to be an intermediate layer where it's easy to define semantic classes as composites of utility classes. I would think this should be possible in the days of Less, Sass, and precompiled web sites.

You shouldn't need to know what the exact visual style of the button is. That's not important. You have a button, it's the primary button. What else do you need to know when coding your HTML?

Hey! I'm using basically a Bootstrap-like syntax for my own "framework" at work. We've been running it for almost 4 years so I'd love to respond to everything your saying:

1. it does actually happen but more often than not, individual buttons need some changes.

2. absolutely but that's why we use SCSS to help "cascade" those changes. Unfortunately, those large changes, again, require individual tweaks in some tricky areas.

3. adding classes is always the safer approach. One thing that has helped us is to make sure classes hold little (but valuable!) responsibility.

4. this is an awesome question. So, for us, those little adjustments specified in the post (small margins and so on) were tweaked at component-CSS level while large-changes were kept to our SCSS framework

5. It's basically CSS-in-HTML

So my own experience has taught me a general approach of my own:

1. create a framework for your site in SCSS. This includes basic styles for buttons, input boxes, colors, typography, tables etc. but stay away from more complicated styles (like trying to create CSS for a "profile card")

2. keep "component" CSS inside a component. Profile card CSS goes in profile.component.scss

3. overrides/hacks belong to where those overrides/hacks need to happen.