Minid the blog, August 12, 2019:

In defense of Functional CSS

I recently had the opportunity to read more articles and forum posts about CSS Utilitarianism or Functional CSS as some might have known it. These articles and comments in general are against this methodology. Not exactly everyone is against it. Most people who’s against this methodology doesn’t understand it completely —and, believe me, I understand them—. They only see the wrong problems as the biggest trade-offs. Basically, for those who are not yet aware of what is being discussed over the last 3 years; there are two recent trends in the frontend development world: those who believe that programming with encoding structural annotations in string names (BEM, object-oriented approach) is the best and those that use the functional form of CSS as a way of development (single-class utility purpose). Both methodologies have their pros and cons, however, when analyzing both, these articles never make a fair analysis of Functional CSS, leaving the impression that the current popular way of writing CSS is the only effective way to do it.

At the time of analyzing and giving judgment on both methodologies in articles, we must recognize these problems of the current web development as the biggest trade-offs to have in mind but that they never do correctly:

• Code recycling is an urban legend.
• People always forget the Technical Debt.
• People never really talk seriously and deeply about performance.
• People assume that everyone will know how to build good CSS architectures.
• People forget that employees come and go in companies.
• People forget that it is complicated to retake up projects.
• Some people believe that it is only a problem of communication between employees.
• There is an absurd fear to increase the HTML size.

It is because of these arguments that Functional CSS has convinced me that it is the correct way, at least for now until the empirical evidence tells me otherwise. Given the volatility that exists on the internet, investing so many hours and personal health in creating “the perfect architecture” makes little sense when you can be explicit in intentions in the same code. Such is the conviction that I have, that I even disagree with the position of Jeffrey Zeldman on this subject, imagine that!. I’ll comment on the points of Jeffrey —whom I admire— and, with whom I have just 2 years of difference of professional experience on the Internet.

Recycling code is an urban legend

In 25 years working as a developer or leading projects as product manager, I have never recycled 100% code or I never saw people recycling code to an interesting level, I repeat it again, I have never seen a significant recycle of code. Do not believe that I have worked on the same project all my life, I have directly participated in more than 100 websites creations and more than 25 on native platforms for smartphones. I want to believe that someone on the Internet made a big project, just touching CSS without changing the whole HTML structure as well as the critics of Functional CSS preach. What I usually see is people starting from scratch all the time. Most devs told me on this matter that “it’s faster to start from scratch than undo countless lines of legacy code”. They may import some parts of the code, but the whole idea of “only develop in CSS” is kinda an urban legend. This bias started when examples such as Zen Garden and preached that CSS was powerful because it allowed you to change the entire appearance without touching the HTML. This bias perdured over the years but nothing could be further from reality: every web project that could be redesigned not only mutated all its HTML code from scratch, but also its CSS code. In my research on CSS I show it: all the internet projects that I researched since 1996 have always made drastic changes, but even more terrifying is knowing that while they maintained a style of development, the code does not stop growing, therefore, affecting the loading, rendering and painting performance of each web document.

CSS Zen Garden was, in my opinion, one of the best experiments on web development to demonstrate the flexibility of development that existed in HTML and CSS, but not to demonstrate that you would never again need to touch up your HTML code whatever the project. In 2003 –when this project was born– the average weight of the CSS files was 6KB. Today (2019) we are at an average of ~500KB, so using the CSS Garden argument card is, in my opinion, wrong. First, because it never adapts to the reality of developments, second because the difference in code size required is higher when new development parameters are taken, based mostly on philosophies such as BEM or others. CSS Garden is a web document, with just 54 CSS classes, against more than 2000 classes that can be found in current projects.

The code recycling argument has failed. No one recycles code as the UCSS detractors preach. No one. Neither Zeldman has done this in his projects and you can check it by going to the internet archive. It will always be an absurd argument, because since we implemented CSS, the argument of not doing everything in HTML has already lost strength. We no longer edit documents as in 1996 or 2001. Today everything is dominated by content generators, JS frameworks, etc. It is no longer a problem, on the contrary, the problem now is to serve things beyond HTML, since it increases the rendering time and total painting of each page.

Site-wide changes can be managed perfectly in the Functional CSS world. Since we edit the templates, we don’t have the feeling that we need to do extra work anymore and we also get the security of site-wide changes are explicit changes that impact our work according to our strategy. In the OOCSS world, you need to understand that changing the contents of one class will impact (or not at all) the entire website, and probably creating more problems. You still can use site-wide CSS rules that can affect everything and that can be managed easy in a separate file, where you can only find “special rules”. This is way better than inspecting 500kb of possible rules.

A methodology that reduces technical debt

Technical debt is a recurrent problem in Development and no methodology is safe from it, but we must recognize which methodology are more prone to suffer it and which methodologies are not. How is it possible that there is technical debt in CSS? It is very simple: if all the architecture is relegated of the mental capacity to define semantically from each developer, over time these will create a redundant and slow code, either by the pressure to do new things, or as the lack of definitions, the need of new abstractions, the employees recycle in the company or the change of service providers. From the election of selectors and slow selectors, property overwriting -and repetition thereof- the technical debt ends up affecting everyone.

How is it possible that Functional CSS does not have this problem? Because it is explicit in context, therefore, we should not think about the context at all but just apply it. To be crystal clear: if you have to create a new structure in your project, you do not have to think what CSS architecture already created serves the purpose, you do not have to think about new forms of nomenclatures and even more, other variants. Simply build explicitly and functionally on the components of JS and your CSS file will hardly grow, unless you need to radically change each design as the size of the browser screen changes, which would present another type of strategy.

Technical debt is bad, really bad, so much so that in the researched projects I verified that the same amount of horrible done code exists and it is carried for years just because it takes too long to fix both HTML templates and CSS. With Utilitarian CSS this does not happen, since the support is legacy by default; since classes are used with explicit instructions of CSS properties (display--block, align-items--center) and not a pack of custom class names as occurs in other projects. FCSS can be written by hand, without the need to use the original framework. While the strictness of its methodology is respected (writing the CSS property name using the original syntax) the support is assured.

About performance and the HTML file size fear

This is a thorn that I always have after reading the comments written by the critics of Functional CSS: they never really talk about performance completely. They only recognize that functional CSS is better because the archives are noticeably smaller, but they do not recognize the rest of the benefits and they mostly shout out the fear of the size of HTML will be bigger, therefore, it’s a big problem for them to make the switch. They mostly argue that it has a solution: “write good CSS and it will be smaller”. At one point, FCSS is infinitely superior for these reasons uses:

• Tiny file size factor.
• Faster selectors.
• Fewer selectors and properties.

Increasing a bit the HTML file size using more classes names will not be a big deal or a huge trade-off in performance. When you do this, you will realize your website is way, way faster in any way. First, most of the projects do HTML caching, only few parts of the screens are updated (hello React, Vue) and HTML by default will be always the first resource to download and load. Faster by nature. HTML is the first and most prioritized resource that will be downloaded. The average HTML load time is ~52ms against ~600ms of CSS files. If the browser requests more than 6 resources (styles, fonts, images, etc.), STALLED blocking occurs. You can check this on your Google Chrome’s Inspector. When we request too many TCP packets and when we exceed 6 connections, we reach that limit. This means no file is on the browser loaded until those 6 are finished and loaded. This applies to HTTP 1.0 and 1.1 only. Interestingly, this is what causes the STALLED state, which adds countless milliseconds (and seconds too) to the process of loading resources into the browser. Once you acknowledge this, you will realise how much time it is spent on downloading, parsing and loading the CSSOM on the first visit to a page. The cache will only work on some situations, and after that, “the magic” will dissapear too due loading and rendering performance metrics will come up on the stage.

With that said, it is not very macabre to think that everything happens by writing a CSS with a beautiful semantic architecture, as Jeffrey Zeldman well mentions, but that does not mean that CSS is the best. Is it better because it is understood among developers or better because it really helps the web page load, render and paint everything faster? If Jeffrey believes that the most important thing is how well written the CSS is then it becomes clear that performance is no longer important among these people, since they assume a readability trade-off by a performance one, that is, that it comes before the ego or the happiness of the developers over the interests of the users.

The harsh reality is that traditional methodologies, by logic itself, will be never better when it comes to performance. It is enough to note that the OOCSS methodology already repeats CSS properties —increasing the size of the file—by nature, therefore, they are considered anti-performant. I have seen projects with over 1,5 MB of CSS code. This linearly increase the loading time of resources. A 15kb file of UCSS rules is x10 faster in generating CSSOM than a 500kb of rules. They also have by nature the idea of ​​using slow selectors and pseudo-selectors of all kinds: generalists, inherited, attributed. This means that developers are always working in inheritance mode and creating selectors that are slow by default. A functional CSS selector is direct: a class and that’s it. The class .display--none { display: none } will be way faster than: .header .nav .item span { display: none }. When our architecture, by nature of the methodology used, already encourages us to write nested or conditional rules, what we are doing is increasing the time it takes to render the page. Every page visited will pay the price to render. And this time is always random because it will be affected by other resources and computer conditions (ex. CPU priorities, memory rewriting).

On the other hand, UCSS starts from the philosophical point of always focusing on performance first, encouraging reuse and when it is no longer possible, extending functionality adding more single purpose clases. This philosophy is pro-user: ensure always offer the smallest and optimized file in terms of rules as well as pro-developer, since it encourages the relegation of architectures using an easy understanding and easy maintenance system, although there are developers who believe they would never understand a site made with functional CSS.

On the semantics of the classes

Most people I’ve talked to assumed that everyone —sooner or later— would know how to build good CSS architectures; including choosing the right names for each component. The problem with this argument is it has two main issues: the first one it contemplates everyone will have the same comon sense at the time of choosing the names. Pity that rarely happens and only can be found on the typical layout structures, like head, footer, etc. Once you go out these zones, things starts to get lit. The second point is that it estimates that the developer or the development team will be the same for a long period of time and that they will do it consciously every time without making mistakes in the process, but the reality dictates the opposite: employee turnover is immense. Search studies on Internet and get scared with these incredible numbers: like “44% of employees say they would consider taking a job with a different company for a raise of 20% or less” or “65% of employees are confident they can find a better position that pays more”. The employee turnover and retention is a hot topic, specially on IT. So much so that many people are likely to change projects, companies, suppliers and, consequently, the essence of the original architecture will be lost for sure when new additions get into the company. They will look at the code and scratch their heads with countless lines of CSS and HTML that has to be learnt in order to understand the architecture. Most of them will refactor it to their vision of CSS architecture and a lot of them will just add their own architecture creating multiples architectures in the same CSS file. This is so common that in some big projects you can see 3 o 4 styles of coding. Let me know how that can be superior to Functional CSS and a benefit for the customer.

Of course, you can argue that everything can be solved by writing “a well done style guide”. Documentation about CSS in a company is kinda like an urban legend too. The style guides are something so unusual to find that, when I run into some kind of document that explains the CSS, I find that it has been written with haste, as if it were something unfortunate to do and there was no choice. In 25 years experience working in projects I have never found well maintained documents. Rather, it was always not finding documents at all. Landing at a project already involves wasting a lot of time understanding how the architecture was made and how classes can be taken advantage in our development tasks. The existence of a style guide does not imply that the architecture will be respected or that there is no abuse in the code. Guides without someone who enforce it are plainly useless. They are like speed signals in the roads while cruising in the middle of nowhere: people don’t even respect them.

It is much easier if you have to change something in UCSS: one opens the JS module, HTML whatever you want, and right there you make your changes by reading the explicit CSS, as if it were inline CSS but with the power of the classes. You don’t have to think about class nomenclatures, you don’t have to think about dependencies, you just have to apply the context and it is explicit.

Is not about team communication either

25 years ago there was no code review concept in web development. We simply uploaded the changes to the servers and then, when it was too late, we made the relevant arrangements. Today we have another type of workflow, full of tools that do hundreds of tasks automatically and above that, we have code reviews. If in your company you don’t do code review, you may be alone or you will be already in a big hurry.

Today, communication between teams is more obvious and direct. We have Slack channels, Git, sprint meetings, etc. The problem isn’t to dispose of means for communication but more to reach an agreement quickly and efficiently. It is difficult to agree on what class names to use, re-use, modify, etc. The list of issues goes on until you fall asleep with this matter. That is why the functional programming in CSS is more explicit and removes all types of friction when composing a component. You do not have to ask a co-worker which class name to use, or what modifiers would accomplish the job or read outdated and poorly written style guidelines, no, you directly write the necessary CSS classes to achieve the design and that’s it.

There is no more mystery here. There are no worries of the kind of “but, will I brake something elsewhere in the site by modifying this?”. All these things speed up the development and the way in which the employees work, taking away a lot of stress from reviewing and checking that what they are doing cannot break something already done by another or increasing the speed or technical debt of the product.

People forget that it’s complicated to retake up projects

Sometimes we sin naively in believing that we will always remember all the code we’ve done. It always happens because the security of making our own code biases us with the idea that in the future, I can open this project and continue working as if it were done today. The reality in my career has been the opposite and when I talk with students about this subject, I have also concluded that retaking architectures made by us is not always a guarantee that we can understand it instantly, specially on those projects that weren’t touched for long periods of time.

There is the possibility of having a better idea, but not a complete idea of ​​what has been done. We can remember and guess things because we always use the same names and some structures we repeat until we are fed up, but then there are other more specific cases and that is where we begin to suffer our own creation. Recently I have rewritten a large personal project, made with BEM to FCSS and it has been funny to realize how lost someone can be and the mistakes someone finds even when reading old code. The original file, without compression was 42,9Kb and the final FCSS file ended up being only 12,6KB. Things like “I would have done this differently” are repeated every 10 minutes of code analysis. Sometimes you even grab your hair when you realize how complicated it was when you coded something, that’s why for me, resuming projects made with FCSS are no longer a problem because what I need to touch is there, at hand and easy to understand. The architecture is abstracted from the CSS therefore, I do not worry more about relearning how I made the grid in a project, but in applying the relevant changes in the place they touch. I can come back 2 months later to that personal project I’ve been porting to UCSS and feel like I was coding it today.

Why is it possible to work with Functional CSS

Some people I have read on Hacker News and on Twitter have expressed their concerns when doing projects with functional CSS. Their concerns are based on the comfort of development, the complexity of the project (can I do X with functional CSS?), speed, learning curve, etc. All this is solved by doing a small personal project and seeing the results and then escalate to bigger things. Maybe the first times you will feel awkward but after you tasted the sweet side of Functional CSS I will tell you: you’ll never want to look back.

In my case, I have reduced at least 3/4 the amount of time used to build and deliver the product thanks to CSS programming. In terms of complexity, it is where I have noticed most profit: I no longer think about architecture but what properties my component needs to look 100% like the design they have given me. The speed of composition using one-use classes is fast, way faster. It is clear that each person has a different speed but in general you will notice a significant increase in working speed once you get used.

Like all methodologies, it simply requires you to practice it until it becomes the default option in your workflow. It will take you less time to assume how to code with UCSS than understating the proper way to doing CSS architecture for your projects.