In Defense of Functional CSS - Minid.net<br>August 12, 2019<br>In Defense of Functional CSS
Functional CSS is still treated by some developers as a messy or undisciplined way to write interfaces. I think that criticism misses the point. Functional CSS can reduce CSS growth, make changes more explicit, and lower the cost of maintaining large front-end projects.<br>Functional CSS has always had a branding problem. To some developers, it looks like chaos. Too many classes. Too much noise in the markup. Not enough poetry in the stylesheet. To others, it is a practical answer to a very old problem: CSS architecture sounds great in theory, but in real projects it often becomes a museum of forgotten decisions, abandoned naming conventions, and selectors that nobody wants to touch.
In front-end development, the debate is usually presented as a fight between two worlds:
Traditional CSS architecture: BEM, OOCSS, SMACSS, semantic class names, component-specific selectors, and so on.
Functional CSS: small, single-purpose classes that apply one job clearly and directly.
Both approaches have trade-offs. That is not the problem. The problem is that Functional CSS is often judged unfairly. Critics focus on the HTML looking busy, then ignore the bigger issues that happen every day in real projects:
CSS reuse is often exaggerated.
Technical debt is usually underestimated.
Performance is discussed only when Lighthouse starts shouting.
Naming things is treated as if every developer has the same brain.
People leave companies.
Projects are paused, resumed, outsourced, inherited, and rewritten.
Documentation is usually missing, outdated, or written with the enthusiasm of someone filling tax forms.
There is a strange fear of adding more classes to HTML, even when the alternative is shipping large, fragile CSS files.
My position is simple: Functional CSS is not perfect, but for many projects it is the better default. It is explicit. It is predictable. It keeps CSS files smaller. It reduces the amount of hidden architecture a developer must understand before making a change.
And, yes, I know this position annoys some CSS purists. That is fine. CSS purists have survived worse things, including Internet Explorer 6.
Code reuse is often exaggerated
One common argument against Functional CSS is that it does not support code reuse. I think this argument is weaker than it looks.
In more than 25 years working as a developer, product person, and manager, I have rarely seen CSS reused at the level people claim when defending traditional CSS architecture. I have worked on many websites and native products, and the pattern is almost always the same: when a redesign happens, teams do not simply update the CSS and keep the HTML structure untouched. They change the markup. They change the components. They change the layout. They change the design system. They change half the product and then act surprised that the old CSS does not fit anymore. Sometimes teams import pieces of old CSS. Sometimes they preserve a few utility classes, resets, tokens, or variables. But the romantic idea that developers can redesign a serious product by only touching CSS is mostly a myth.
CSS Zen Garden was a brilliant project. It showed the power of CSS at a time when many people still treated it as a minor styling layer. It proved that a single HTML document could support many different visual designs through CSS alone. But CSS Zen Garden was also a controlled experiment. It was not a SaaS platform with dashboards, modals, data tables, settings pages, permissions, responsive states, user-generated content, A/B tests, and five teams pushing changes before lunch.
Using CSS Zen Garden as proof that real products should avoid changing HTML during redesigns is like using a Formula 1 car to explain why your family car does not need a trunk. Beautiful example. Wrong context. Modern web products mutate constantly. Their HTML changes. Their components change. Their interaction models change. Their business rules change. And when that happens, CSS architecture usually changes too. Functional CSS accepts this reality. It does not pretend that a perfect semantic layer will survive every redesign. It puts the styling decision close to the component, where the work is actually happening.
That is not a lack of discipline. It is honesty.
Functional CSS can reduce technical debt
No CSS methodology eliminates technical debt. Bad Functional CSS exists. Bad BEM exists. Bad everything exists. Give a team enough pressure, unclear requirements, and no review process, and they can turn any methodology into a crime scene. The question is not whether Functional CSS prevents all technical debt. It does not. The better question is: which methodology makes technical debt easier to see, easier to limit, and easier to fix?
Traditional CSS often hides complexity behind class names. A class like .card--featured looks clean, but the real behavior may live in several selectors,...