It’s been a long time since I read a book from cover-to-cover in one sitting, but today I set out to read Jonathan Snook’s Scalable and Modular Architecture for CSS (SMACSS), which was so short and readable that it might be difficult to not finish in one go.
Also, it also means a long review would be pointless.
Snook’s book is remarkably easy to understand1 and read. His advice is pragmatic rather than dogmatic, reflecting a balance between considerations of front-end speed, code maintainability, and logical separation of concerns.
The number of major insights in the book for me were few, but important:
- A logical division of CSS code into 4-5 parts, with sub-parts (Base, Layout, Module, State, Theme) – Snook’s division seems a bit arbitrary, but it’s practical. There are only three zones here of logical categorical separation that I recognize, but Snook’s division seems to better reflect how the DOM is typically set up, so I applaud him for that. Plus, coming up with a good categorical separation for CSS has always been an exercise in frustration for me, as someone who’s used to more easily doing it with packages, modules, classes. Thankfully, he’s done the work for me.
- A class-heavy model for CSS organization – I’ve known for a while that it’s better for performance reasons to use CSS selectors (preferably ID’s and classes) which match on leaf nodes, but I get flashbacks of the early days of class proliferation ad nauseum when I think about implementing that on large sites. More importantly, Snook shows that you can still have standards of organization when using more specific classes, by making fake module compositions using naming conventions.
- Some moderating advice for CSS preprocessor users – I love SASS. LOVE it. Variables, inheritance, composition, functions — they make sense and they save time. Unfortunately, as Snook points out, I probably often over use the fun features of SASS. Preprocessors can be used for good and for evil and the book points out some of the frequent overuses of SASS / LESS / Stylus.
Snook is careful not to push too much of his system on the reader, so there are very few recommendations which don’t come with a caveat. I dig that. Unfortunately, it leaves me with little to complain about, so I’ll just mention things I wanted to see in the book that weren’t there (perhaps topics for a sequel). What was missing?
- SMACSS with major style frameworks (e.g. Bootstrap) or front-end libraries – there are a few examples with Bootstrap in SMACSS, but I get the feeling that going whole-hog SMACSS will present an increasing number of problems. Because the SMACSS methodology relies on lowering the specificity of rules, my CSS rules seem more likely to be overridden by those of included tools. I would have liked to see some more strategies for dealing with this.
- SMACSS with web components (HTML5 Templates) – this is probably unfair of me to ask for given the publishing date, but I’m curious about how Web Components will alter the scene for selectors and code organization. SMACSS does include examples for working with Mustache, which is a good start, but there are additional isolation rules coming (or here, in the case of Chrome & Firefox) to browsers with this support.
- CSS static analysis tools or techniques – I’d particularly like to see tools for encouraging or enforcing SMACSS-like behaviors. Unfortunately, my experience is that people are unlikely to keep their patterns neat unless there is some means of enforcement.
- I’ve been mired in CSS for a long time, but I wouldn’t consider CSS / front-end to be my area of expertise. [return]