“Favor composition over inheritance”. This piece of wisdom from
Design Patterns,
one of the most influential software engineering books, is the
foundation of utility-first CSS. It also shares many principles with
functional programming: immutability, composability, predictability,
and avoidance of side-effects. The goal behind all those fancy terms
is to write code that’s easier to maintain and to scale.
While gaining traction as a symbol of Mexico City, these curious
amphibians offer hope for healing the human body, but face near
extinction in the wild.
Over the last several years, the way I write CSS has transitioned
from a very "semantic" approach to something much more like what is
often called "functional CSS."
Writing CSS this way can evoke a pretty visceral
reaction
from a lot of developers, so I'd like to explain how I got to this
point and share some of the lessons and insights I've picked up
along the way.
Functional CSS is a contentious topic, and one that regularly
generates heated comment thread debate. In such situations, it can
be tricky to tease out the hyperbole from the measured opinion.
Here’s my view on the subject, based on my recent experimentations
with the approach during a project to build a web application.
In the evening I modified the NGINX configuration for Plurrrr to
support HTTP/2 using the above article. This resulted in a
Lighthouse
mobile audit
Performance score of 100 and a Best Practices score of 100.
Lighthouse mobile audit score for Plurrrr.
The low SEO score is in part caused by Plurrrr having an empty robots.txt
file. According to Lighthouse:
robots.txt is not valid Lighthouse was unable to download a robots.txt file
