Two Steps Forward, One Step Back
3/6/2020 If you’ve ever seen code that looks like this, I’m sorry: I’m sorry If you’ve ever seen code that looks like this, you’re welcome: Hello Back in 2013, Adam Morse and I were following along the incredible work that Nicole Sullivan and others like Nicolas Gallagher were doing with Object-Oriented CSS (OOCSS). Our explorations around working with CSS-related tech-debt led to the creation of Basscss and Tachyons and the birth of “Utility CSS”. These libraries inspired other design systems such as Buzzfeed’s Solid and GitHub’s Primer CSS. Even Bootstrap eventually added more utility-centric styles. This methodology became known by many names, including Atomic CSS, Functional CSS, and Utlity CSS, but I’ve started referring to it as Atomic/Functional/Utility CSS or AFUCSS. This sort of sounds like Hey, F you!, which is a pretty typical response when most people first encounter this flavor of CSS. What problems did this solve? Whatever your opinion on this methodology was, it tended to help with a few common problems of working with CSS at scale. It connected elements directly to styles, avoiding selector abstractions and the need to name things. It encouraged designers and developers to use scales and constraints on margin, padding, font sizes, colors, and other properties. It helped mitigate “append-only” stylesheets by reusing styles. It avoided some of the pitfalls of “specificity wars” incurred by the cascade. Although it had a learning curve, once you had internalized one of the many implementations, it could increase your development velocity. Around the same time, we started working on CSS Stats, which helped validate some of our hypotheses about CSS filesize and front-end performance. Applying this methodology to production web applications at the time helped shave of hundreds of kilobytes of CSS that was being shipped to end users. What did it fail to do? Despite Tachyons’ popularity, no single library ever took over the industry at a level that would negate the steep learning curve involved. This meant that not only did developers have to learn a new methodology, but also an inevitably large custom classname API. CSS is a powerful and nuanced language, but utility CSS can never fully replace it. Eventually, you’ll need to add one-off styles that just aren’t covered by the library you’re using, and there isn’t always a clear way to extend what you’re working with. Without a clear way to handle things like this, developers tend to add inconsistent hacks and append-only styles. As any utility-based CSS library grows, so does the amount of CSS you ship to your users, leaving you reliant on more build tools to remove styles that you were never going to use in the first place. While it was generally better than other methodologies at the time with regard to CSS filesize, it still wasn’t ideal. It’s also worth noting that this methodology was created before React was released and was intended for use in template-based user interfaces, including Rails and PHP. It was never designed for functional component-based UI and doesn’t take advantage of this new paradigm. » Read More
Like to keep reading?
This article first appeared on jxnblk.com. If you'd like to keep reading, follow the white rabbit.