My CSS in 2014

A few totally self-indulgent rambling notes on my year in CSS...

CSS architecture is a solved(ish) problem

The most remarkable thing about the CSS I wrote in 2014 is just how unremarkable it was.

I mean this in a good way. Apart from a few minor tweaks, the way I write CSS hasn't really changed for a couple of years. I still:

  • Use Sass (though I'm using fewer of the language features)
  • Write SMACSS-inspired modules using BEM(ish) syntax
  • Do most layout & positioning with empty child elements that a module positions within itself (Andrew Colclough explains it nicely in Objects In Space)

Our team has grown and our old codebases have evolved, but our CSS has remained understandable & maintainable. Starting new projects is easy - I just bring in Normalize and create an empty modules folder.

Most people I talk to are using OOCSS, SMACSS, SUIT or BEM (or a mashup of them that works best for their team) and it seems to be working out pretty well.

I keep seeing this old chestnut show up in talks & blog posts:

The Family Guy CSS gif. You know the one.

I kinda think that if CSS still feels like this to you, you must be trying pretty hard to ignore everything that's happened in CSS architecture over the last few years.

The existence of adequate CSS architectures hasn't stopped people pushing things further though...

Trait-based CSS

In 2014 I noticed myself leaning pretty heavily on what SUIT calls Utility Classes - rather than specifying many properties inside a single module class, common patterns are extracted into simple classes and composed together in HTML.

It turns out composing utilities together like that is a really nice way to style things.

Adam Morse has taken this to its logical conclusion with Tachyons, while Glen Maddern & Ben Schwarz gave us a much nicer method than classes for declaring these traits in HTML with Attribute Modules - both very cool projects that I've been experimenting with.

One of the downsides of trait & utitlity styles is that once they're defined, they very quickly start being used in a ton of different contexts throughout your application, making change quite difficult.

My gut tells me that the strict scoping of module styles means they're more maintainable in the long run - you can change or delete them confidently, knowing that they don't behave differently in different places - but time will tell!

Styling with JavaScript

My adventures in React in 2014 eventually led me to a project by Sander Spies & Andrey Popp called react-style (read the intro blog post).

The idea of styling with JS instead of CSS is kinda sacrilegious (see the comments on Jenn Schiffer's masterpiece on the topic if you don't believe me) but after experimenting with it for 5 minutes I was pretty sold on the idea. So much so that I gave a talk on it at MelbJS & MelbCSS.

Something just feels right about writing an entire component - its structure, style & behaviour - in one language and one place.

There are a few similar libraries floating around, and Christopher Chedeau did a great presentation on it (though I don't quite share his opinion on the dire state of CSS at scale).

I'm not using it on any projects yet, but I think there's something to this idea. I'll be watching it closely in 2015!