Cole Peters has written a great piece on his work refactoring the TrialReach CSS codebase:
A functional approach to CSS has thus far played out really well for us at TrialReach — we’ve significantly reduced complexity and bloat in our CSS, and find ourselves reusing existing styles far more often than we create new ones…
A few quick notes about Cole’s post that I find interesting:
- The style guide acts as a guide, rather than as a final arbiter of good design.
- I’m still not sure about the readability of class names such as
u-py4. However, if you choose to make classes likeu-padding-top--smallinstead, and you’ll have a lot of functional classes like that, then developers will end up having to parse a lot of text to see how everything works. Perhaps abbreviating classes in this way is just one of those things you get used to the more you use them. - Lots of classes in the markup is not a Bad Thing™, either for developer usability or performance.
- There’s never one solution for all our front end problems: I’ve used an approach like this before on much smaller projects and it only appeared to get in the way of me writing code. Some websites don’t need to be maintained by multiple developers and in those instances the quality of the codebase can be, well, flexible.