The One About Nested CSS and differences between "Easy" and "Simple"

Rich Hickey gave a really excellent talk in 2011 at Strange Loop about the difference between 'Easy' and 'Simple'.

The talk challenges some current best practices in the software industry that optimize for ease-over-simplicity.

I'm going to take the gist of the talk and apply it to CSS where the last few years have seen an increased drive toward a similar simplicity but with a different veneer.

Hickey draws the distinction between Easy and Simple. He makes it clear that although they may seem similar at first, closer inspection reveals that these terms refer to quite different things. He argues that Easy things are familiar and usually part of (or within reach of) our skillset. Simple things, by definition, are not Complex. They are unentangled.

Software writers tend to champion constructs (e.g. tools, languages) that are easy-to-use. These constructs often produce complex artifacts (tangible stuff, e.g. the application that was given life at the end of your build/deploy process).

Easy things are within reach of skills that we may have already developed, and they are optimized heavily for early speed, but they ignore complexity. Over time, the growing complexity can reduce speed dramatically, even stopping work entirely. Have you ever seen a system that was so complex that meaningful work could no longer be done in it?

On the other hand, Simple things are not optimized for early speed, but because of their nature you do not end up with complexity. You will consider your implementation strategies more carefully. You will probably end up faster over time.

The true value of software is in the quality of the artifacts that it produces. The artifact is what makes it to the user, not the construct. Complexity makes it harder to fix bugs and more difficult to reason about the system.

"The User is not looking at our software and they don't actually care very much about how good a time we had when we were writing it. [...]

If it works well, it'll be related to whether or not the output of those constructs was simple. [Did the constructs yield complexity?]"

— Rich Hickey

Hickey's talk goes through a lot of tools that lend themselves to complexity (e.g. state, inheritance, ORMs), or simplicity (e.g. functions), but the way we construct our presentation layer on the web isn't part of the discussion. In light of that, it's interesting how directly-and-penetratingly the principles apply to CSS pre-processors.

Nesting CSS styles via pre-processors is very convenient for developers. It's a wonderful developer construct but it introduces lots of unnecessary complexity to the CSS artifacts we're generating.

Here are some of the problems with the artifacts produced by nested CSS:

Nicole Sullivan (@stubbornella) said "Never go more than three levels deep!" in reference to selector-nesting at JSConf almost three years ago (homage to Inception).

Great coders like Jacob Thornton (@fat) and Harry (@csswizardry) think it's best to not nest CSS at all.

Nicolas (@necolas) has been telling us for a few years that we need better structure.

Adam Morse (@mrmrs_) has similarly been teaching us that simpler is better.

Soon or later that app is going to get big, and some time after that, it will have to change. Simplicity is usually better for dealing with that change.