Tachyons CSS - first impressions

Tachyons CSS - first impressions

  • Date
  • Author

Mastering CSS is something of a paradox. On the surface it’s a pretty easy language (if it can be called a language) to learn. Anyone that’s prepared to spend a couple of days reading the right material and following a few tutorials will get to grips with the basics.

Yet at the same time, CSS is a beast to master. When projects become more ambitious and when they involve teams of developers, developing performant and maintainable CSS becomes an architectural challenge that I don’t think anyone has ever really conquered.

I’ve been building websites for longer than I like to admit, and after all these years and all these websites, I’ve never discovered the one true way™ to write CSS. From my early monolithic stylesheets where I used to write a selector’s styles all on one line (yep, I did that), to today’s myriad of build tools and methodologies such as OOCSS, SMACSS and BEM, my approach and CSS has definitely advanced. But I’ve never shaken the sense that somehow there’s a better way to do this.

Enter “functional CSS”

Functional CSS (sometimes referred to as atomic CSS or immutable CSS) is an approach that promotes the use of very small, immutable classes - often consisting of just one property - that are created to do one job and do it well. The classes are then composed in your markup to construct complex layouts and components.


.mv3 {
  margin-top: 1rem;
  margin-bottom: 1rem;
}

.pa2 {
  padding: 0.5rem;
}

.bg-light-silver {
  background-color: #aaa;
}

.ba {
  border-style: solid;
  border-width: 1px;
}

.b--dark-gray {
  border-color: #333;
}

<div class=“mv3 pa2 bg-light-silver ba b--dark-gray”>
  // panel content
</div>

I first came across this approach when looking into the Tachyons CSS framework, which I’ve been using on a project I started last month.

Tachyons - chocolate spread and cheese 

At first glance, Tachyons looks, honestly, just wrong. It feels like the complete and utter opposite of everything you’ve ever learnt about CSS. It’s an almost instinctive response to wrinkle your nose and mutter something about "doing it wrong".

But I was inspired to check out Tachyons because I kept seeing smart people who I respect making positive noises about it. Maybe they're the enlightened ones who have realised the surprising pleasure of chocolate spread and cheese? But there’s no doubt about it - functional CSS does require a degree of “unlearning” years of ingrained habits and approaches to writing CSS.

In essence, functional CSS removes complexity from your stylesheets. Classes no longer represent complex objects, instead they represent simple functions that do one thing. Consequently your stylesheets become much smaller and much easier to reason with.

On the flip side, that complexity ends up in your markup. The class names can be a little cryptic and sometimes you’ll need to chain ten or more classes together to achieve the desired results. So your HTML becomes verbose and cluttered with styling directives.

Instinctively this feels bad, but when you sit down and think about it I’m not sure how much of a problem this is. As long as a project’s design process is thinking in terms of reusable components, and there is effective use of templates, class-heavy markup is little worse than stylistically being a bit ugly.

Working with Tachyons

I’m genuinely enjoying working with Tachyons. It is, dare I say it, fun. The main benefit I’ve realised at this point is it’s very fast and efficient to prototype some components and turn them into a solid, functioning and reliable design.

For the most part, the standard base that Tachyons provides is sufficient and sensible. However, on occasion you’ll inevitably need more from your CSS than Tachyons provides. I’ve found it works best when you go all out on the functional methodology.

I’d initially experimented with mixing abstract object/component classes alongside Tachyons’ functional classes, but it quickly felt inconsistent and messy to be mixing the two approaches within the same component. It was difficult to understand where the boundaries between functional and object oriented CSS should sit.

My preferred approach now, when I need more bespoke styles than Tachyons provides, is to define additional functional classes following the (mostly sensible) Tachyons class naming conventions.

Where I make an exception and think outside of the functional paradigm is defining state-based styles. For example, a component’s static styles that are consistent no matter it’s state would be defined using functional classes, and then I’d define a component class with .is-* modifiers for each state-specific variant.


.c-panel {
  &.is-hidden    { /* hidden styles */    }
  &.is-fixed     { /* fixed styles */     }
  &.is-collapsed { /* collapsed styles */ }
  &.is-expanded  { /* expanded styles */  }
}

Conclusions

I’m only halfway through my first project using Tachyons so it’s a bit premature to reach too many conclusions. Ask me again when I’ve had to maintain the codebase for two years.

But right now I’m enjoying using Tachyons and experimenting with the functional CSS way. I always think it’s healthy for developers to challenge the conventions and opinions that stick with us through the years. I can see a lot of people absolutely hating functional CSS and for me that’s a good reason to take a closer look.

Reducing CSS to it’s minimum possible level of complexity seems to be a great way of reducing the inherent problems with developing maintainable CSS. Templates and template languages seem a much better place to handle much of that complexity.

I’ll stop short of proclaiming functional CSS as the one true way™ to write CSS. But it’s certainly a refreshingly different way and worth taking a closer look.

Further reading

Work with us

Interested in what we've got to say? Lets have a chat.

Project planner