How I started thinking about my styles

If I had received a dollar for every time I promised myself I was about to write the most maintainable CSS I had ever seen, I could have bought a lot of coffee by now.

When I started programming as a kid, somewhere in the table-layout era, things were simple. I made one website with one stylesheet. If it worked for me, it probably worked for everybody, mostly because my friends and I were the only ones visiting it anyway. It was fun.

Years and plenty of larger projects later, CSS started to feel like one of the harder parts of web work. Sure, naming things is hard and cache invalidation is harder. But keeping a CSS codebase understandable gets worse with every extra developer. It gets even worse when someone drops a few !important fixes into the stylesheet because it worked on their machine.

I got used to it. That seemed to be part of the job, and at least we did not have to deal with IE6 anymore. Then one day, while going through podcast episodes on my commute, I listened to Full Stack Radio interview David Hemphill about Beard. It is an atomic CSS framework, or as David called it, "a framework for people with better things to do".

That clicked for me. We all know about BEM, OOCSS, and SMACSS. Those approaches can work well, but they often feel better suited to large projects with bigger budgets than to small freelance projects with tight deadlines.

That is where a framework like Beard can fit. It may feel strange at first because we have all learned to avoid inline styles. But instead of inline styles, you get helper classes that can be customized with a preprocessor like Sass or Less.

With a preprocessor, you can even use helper classes as extends. That seems to power the styleguides behind Marvel. I like their fully written helpers more than Beard's abbreviations:

.fdcr // Used by Beard
.flexDirection-column-reverse // Used by Marvel;

For new developers on a project, the longer version is easier to pick up than overlapping abbreviations and exceptions.

It is also not a coincidence that people in the React world are exploring similar techniques.

Should I use this for every future project? Probably not. But it did change how I think about styling: sometimes a small, explicit helper is better than another class name pretending to be a component.