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:
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.
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 :)