My experience has been that the extremely minor performance benefits of functional CSS are not worth the extra time and energy you will spend on a multi-person team trying to mitigate duplicated class names and conflicting CSS functions.

You're welcome to disagree of course, I held a somewhat similar view to you until I tried BEM in a production setting.

And of course, different products call for differing methodologies. I haven't yet switched my personal blog over to BEM, for example.

I did many BEM projects. The idea behind Functional CSS is precisely that: let entire teams work without having to deal with naming. The project becames ultra-maintainable with the best legacy support.

My experience and all the data I've gathered about performance, even coding the equivalent in UCSS was shocking: 400% render speed improvement. 600% loading resources improvements and radical painting speed. To set you in context: one corporate website from a bank, had an average of 230kb resource loading, we lowered it to 33ms. 650ms rendering, we lowered to 90ms. Painting speed avged 90ms, we lowered to 12ms. If you plan things properly, you can radically improve the speed.

It's true that UCSS doesn't make that much sense for very small websites. Although you will render close to a plain HTML doc for sure. It makes sense when you need to repeat and componetize many things. There's when you gain true power. For example, in our tests, we made another equivalent 590kb uncompressed CSS file to 32kb total code need in UCSS. Compressed was about 12kb against 190kb compressed file. That's how you make great improvements.

I've discovered functional CSS some months ago, and I don't think I'll ever look back. Building everything with simple classes makes it easy to keep things consistent, appearance concerns live firmly in the style layer, and once patterns of classes used together start to appear, I can break the rules a little with SCSS and make classes like "button" ("ps ts cap rc2 box1") for the shorthand convenience.

Once you add all of those classes, it's nearly impossible to add a developer who isn't used to it. It's also really hard for me to read. Tailwind / bootstrap etc - is a total deal breaker for me. I'll just get a different client. https://www.browserlondon.com/blog/2019/06/10/functional-css... I just can't imagine not writing CSS like this: https://maintainablecss.com/chapters/introduction

Specially if you work with reactive HTMl, like VUE or React. It's a win. Even with old MVC frameworks you can work confortably and have inmeasurable performance and development speed. The CSS becomes so easy to read, mantain. Changing things is way faster. Back then I needed to watch so many things to do the job. That's why I lost my OO CSS bias.

But does bloated CSS matter?

If a human isn't going to read the CSS and the computer handles it without performance problem, I say no.

Those are of course two quite important ifs!

It matters.

First, not all users need your huge CSS file, in terms of downloading. Specially when they're on mobile phones and cache is crap.

A ~9000 rules CSS file will load and become COSSM slower than one that has 1000 or 10. It is linear increment. Make a test to see it for yourself.

A bloated CSS is more network time. Therefore, slower loading.

A bloated CSS will contain slower selectors, therefore slower rendering time and painting speed.

When you count all these things, you will see radical speed performance.

Maybe. You need to measure these things and get a feel for the actual performance impact to make informed decisions.

Rule 1 of performance: Your intuitions are not reliable.

Upthread, this commenter did post specific measurements from production projects.

Does download size matter? Why bother with compression or minification?

https://jakearchibald.com/2019/f1-perf/

No. No way. If you're CSS is a problem - then you are doing something really really wrong.