Rationalizing Functional CSS

The idea of functional CSS just seemed like the craziest thing I’d ever heard of. "Why would I ever use this? I’m awesome at CSS," I’d tell myself.

If you haven’t heard of it, functional CSS (or atomic CSS/utility classes/immutable CSS – I could go on forever. There’s not a good name) is the idea that instead of writing big, monolith components in my CSS, I write small, single property, immutable classes that can be assembled into a larger component in HTML.

Your CSS might look like:

.p1 { padding: 0.5rem; } .flex { display: flex } .red { color: red; } 

Which then get constructed into your HTML:

<div class="flex p1 red">   Hi, I'm a flexbox div with 1 unit of padding and red text! </div> 

Crazy, right?

I loved writing really clever, powerful CSS classes. I argued for it because of "ease of developer consumption." My goal was that a developer could add a single class to an element and it would automagically do everything for them. Basically, the opposite of functional CSS.

Then I read Adam Morse’s epic essay, CSS and Scalability . Adam takes you through a very informative journey, so I recommend setting aside 20 minutes to read through his thinking, but if I had to summarize it, it’d be this paragraph:

In [the monolith] model, you will never stop writing css. Refactoring css is hard and time consuming. Deleting unused css is hard and time consuming. And more often than not – it’s not work people are excited to do. So what happens? People keep writing more and more css.


Okay, Adam. I’m sold. You’re right. It’s fun starting a new project and writing all these beautifully architected CSS components, but the fact is, I won’t always be there, and in the monolith model, the team will never stop writing CSS .

Raise your hand if you’ve ever walked into a really well architected CSS codebase.

Me neither.

Typically it’s not because the codebase started badly. It’s because as writers of CSS, we are taught to sling more code to fix any problems.

Much like Adam, I’ve reached the point in my career where

I’m not very interested in what I can do with css. I’m interested at this point in what I can help groups of people do with css.

Basscss and Adam’s own Tachyons were a great starting point for experimentation. I was convinced after testing it out, and I had the chance to kick off a new client project using this approach to writing CSS.

3 months into a functional approach to CSS architecture, I’m addicted. The times I’ve used the old monolith approach, it’s become a tedious challenge in jumping between files constantly. I think I’m convinced, but I’m still trying to rationalize scalability issues as my functional codebases grow and evolve.

I’d love any feedback on what I have or haven’t considered.

The Good


My goodness I can work fast! I’ve always said that I can’t "design in code" and preferred to start any blank slate design in a tool like Sketch. I joked that it felt like two different sides of my brain that just wouldn’t mesh.

What I’ve realized by using functional CSS is that it was the context switching that killed my creativity. I’d have a great design idea, but then I’d have to toggle over to my CSS file and start building up a component from scratch – naming it, thinking through the box model implications, DOM structure, best architecture practices, etc. This was like my creativity hitting a wall at 100mph.

Instead, I cruise through the DOM, writing HTML and quickly styling each element as I go. Using Basscss plus a few custom CSS classes for my brand colors (less than 75 additional lines total), I was able to build out a home page for a project in an hour that’s withstood the test of time.

This alone feels like enough to keep me using this approach. It’s addicting, and I don’t know that I can ever go back. Jon Gold was right:

"The best CSS is the least CSS possible"

— gold (@jongold) April 22, 2016

From a design perspective, Functional CSS frees you from having to make code decisions while designing. The decisions have already been made and you’re simply mixing and matching to achieve your desired styles in the same way that you’d use shapes, colors, and spacing in Sketch.


On most projects I work on these days, our design and development teams have settled on the idea of design providing an HTML/CSS prototype and the Dev team porting that into the real environment.

The efficiency gains on these projects have been enormous.

A code prototype gives our designers time to perfect the user interface without the headache of having to learn to work in advanced JS frameworks like React or Angular.

The issue we’ve found with this approach are the small differences in the HTML required: things like requiring a component or directive to be wrapped in a tag can break your CSS cascade pretty quickly.

In the past, this meant maintaining an app-specific set of overrides, which over time led to more and more bugs (and bad CSS being written).

Instead, small tweaks like margin can be adjusted with a single class change in your HTML. It allows you to fix bugs without writing any additional CSS . I can’t even tell you how amazing this feels. Writing more code to fix bugs the wrong way to fix your CSS.

Stop Making (Pointless) Decisions

Basscss provides a standard set of spacing and sizing utilities. Eliminating choice is actually quite liberating. By only being given 8px, 16px, 24px, etc. has spacing, you just pick a small/medium/large and roll with it.

I used to think this would take away all my creativity, but it’s just made my life easier as a designer. I can focus on the right problems.

The Bad

Before into the issues with Functional CSS, I want to be clear – at this point, these are more questions than criticisms. I’m sure much smarter people than me have come up with solutions (or justifications) for these problems.

I’d love to hear how other people are addressing these problems.

Losing the Cascade

Shifting our style assembly code burden over to HTML means we lose all benefits of the cascade. It’s wonderful the first time you create a component, but updating styles in an existing system can be a complicated mess of find and replace and other keyboard shortcuts.

A simple way to update a few close styles in a single file is to use multiple cursors. In Sublime Text and Atom, selecting a string of text and hitting ⌘-D (on Mac) will select the next instance of that string.

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » Rationalizing Functional CSS

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址