I wrote previously about how I’ve started using the Tachyons CSS framework in my web design/development projects. Here, I want to pen an update for why continues to be my CSS framework of choice. On top of its advantages as an atomic/functional CSS framework, its immutable scale system encourages me to write cleaner code and create better designs.
Let me explain.
One of Tachyons’ core strengths is that it is a toolbox of re-usable, single-purpose CSS classes that are a) mobile first with responsive breakpoints and b) defined on a scale based on powers of two. Take padding for instance:
.pa0 { padding: 0; }
.pa1 { padding: .25rem; }
.pa2 { padding: .5rem; }
.pa3 { padding: 1rem; }
.pa4 { padding: 2rem; }
.pa5 { padding: 4rem; }
.pa6 { padding: 8rem; }
.pa7 { padding: 16rem; }
@media screen and (min-width: 30em) {
.pa0-ns { padding: 0; }
.pa1-ns { padding: .25rem; }
.pa2-ns { padding: .5rem; }
.pa3-ns { padding: 1rem; }
.pa4-ns { padding: 2rem; }
.pa5-ns { padding: 4rem; }
.pa6-ns { padding: 8rem; }
.pa7-ns { padding: 16rem; }
}
@media screen and (min-width: 30em) and (max-width: 60em) {
.pa0-m { padding: 0; }
.pa1-m { padding: .25rem; }
.pa2-m { padding: .5rem; }
.pa3-m { padding: 1rem; }
.pa4-m { padding: 2rem; }
.pa5-m { padding: 4rem; }
.pa6-m { padding: 8rem; }
.pa7-m { padding: 16rem; }
}
@media screen and (min-width: 60em) {
.pa0-l { padding: 0; }
.pa1-l { padding: .25rem; }
.pa2-l { padding: .5rem; }
.pa3-l { padding: 1rem; }
.pa4-l { padding: 2rem; }
.pa5-l { padding: 4rem; }
.pa6-l { padding: 8rem; }
.pa7-l { padding: 16rem; }
}
Starting a new project with Tachyons means I begin work with an already-defined system in place (and yes, it’s easy to customize in case powers of two isn’t your jam). In my experience, having a system in place almost always creates a more consistent design, that is both better-looking and easier-to-navigate.
Of course, there are still instances where I have to declare custom classes for specific spacings/colors/etc. But because Tachyons is already such a rich toolbox, I’m forced to think twice before I roll my own classes – does my design really benefit from having an extra class that deviates from the scale/system? Much to my surprise, the answer is often a resounding no.
As Tachyons co-creator Adam wrote in the Tachyons Slack group:
The ability to declare units at will… always leads to inconsistencies in my experience.
If I absolutely had to deviate from the system I would add another class. I don’t think this applies to over engineering. Over engineering is doing things you don’t need to do. If you have to have it, add it
But in 11 years of front end dev, my experience with magic numbers like 11% is that they are a design smell. People generally pay me to remove such values to improve their design :)
Addendum & bonus
Tachyons community member @DuranCristhian reached out to ask about how I coded custom classes, and whether I followed a different (non-Tachyons) convention for naming them.
What I’ve found after months of using Tachyons is that I try to mimic its structure when I create new classes. In other words, as much as I can, I create re-usable, single-purpose classes that follows the same naming conventions as Tachyons. (Only when that fails do I write bulky custom classes or target nested elements.) And writing light, re-usable classes is always a good thing :)