Full re-write in 10 days with tachyons and functional CSS: A case study (Part 2)
Tags: css, utilityfirstcss, atomiccss, bem
Published: 2019-08-02 20:59:40

---
title: Full re-write in 10 days with tachyons and functional CSS: A case study (Part 2)
published: true
description: This is the second chapter of a 4-post series, taking you through a website refactoring process using tachyons, in which we take a look at what functional CSS is and why it can be useful.
tags: CSS, utility-first CSS, atomic CSS, BEM
canonical_url: https://medium.com/@simonswiss/full-re-write-in-10-days-with-tachyons-and-functional-css-a-case-study-part-2-dd60256b35b2
---

### This is the second chapter of a 4-post series, taking you through a website refactoring process using tachyons, in which we take a look at what functional CSS is and why it can be useful.

### On the menu

1. [Why re-write in the first place?](https://dev.to/simonswiss/full-re-write-in-10-days-with-tachyons-and-functional-css-a-case-study-part-1-3dkm)
2. **What even is functional CSS?** (you are here! 👋)
3. [The refactoring process, step by step](https://dev.to/simonswiss/full-re-write-in-10-days-with-tachyons-and-functional-css-a-case-study-part-3-1k4)
4. [The aftermath: key learnings and recommendations](https://dev.to/simonswiss/full-re-write-in-10-days-with-tachyons-and-functional-css-a-case-study-part-4-4b11)

---

## Chapter 2: What even is functional CSS?

So, what is this buzz all about? What does functional CSS even mean?

You may also have heard of *atomic* CSS or *immutable* CSS. These refer to the same thing. If you're familiar with [pure functions](https://drboolean.gitbooks.io/mostly-adequate-guide-old/content/ch3.html) in functional programming, you should be able to grasp the concept quickly.


---

>A pure function is a function that, given the same input, will always return the same output and does not have any observable side effect.

~ Dr. Boolean, Mostly Adequate Guide to Functional Programming

---

Think of it as breaking your CSS into small, *"do-one-thing-only-and-do-it-well"* classes. Think lego blocks. Combine a bunch of these classes together and you can create just about any style you want.

This radically different approach to writing CSS is challenging a lot of established best practices. It won't be love at first sight.

At first glance, it does seem like a **terrible idea**.

## A basic example

Let's say you want to build an warning box with a red-ish background, some padding and white coloured text.

### The "traditional" way

You'd probably want to write some HTML like this:

{% gist https://gist.github.com/simonswiss/2a49c8cfcdfa1e97932243d2852e8bcf %}

In your CSS file, you could do this:

{% gist https://gist.github.com/simonswiss/a88e0cb6e7b109b9f5d3d29b74f56936 %}

You'd end up with something like this:

![Warning UI built with traditional CSS](https://thepracticaldev.s3.amazonaws.com/i/qmbiu3zwvvgg91457u0w.png)

<figcaption>Traditional CSS warning box</figcaption>

All is well.

Let's now take a look at what the equivalent would look like functional CSS land.

### The "functional CSS" way

Let's split the "looks" of this box series of small, single purpose *attributes*.

Well, I kinda did it earlier. It has:

- a *red-ish* background,
- some *vertical padding*,
- some slightly larger *horizontal padding*
- *white* text.

Let's write a single class for each of these attributes:

{% gist https://gist.github.com/simonswiss/3ac680322ba440d883394322c93d030a %}

We can then use these classes to "compose" our warning box:

{% gist https://gist.github.com/simonswiss/53cb2d8928952b8daabea7a61cc9b929 %}


The result looks exactly the same:

![Warning UI built with utility classes](https://thepracticaldev.s3.amazonaws.com/i/l1zsjfrw6hkkh5nthmn0.png)

<figcaption>Functional CSS warning box</figcaption>

I can hear you scream!

> "Eeeeeewwwww. Why?!"

I told you. **Terrible** idea. The first version is clearly the better way to code this warning box.

Bear with me for a bit.

Let's now build a button for our UI. In traditional CSS, I would do something like this:

{% gist https://gist.github.com/simonswiss/ba7d9562a4d9762ea87507b3f280acd9 %}

and

{% gist https://gist.github.com/simonswiss/67eb8ecde3e08e94a130a090e8117189 %}

We'd get this:

![Button created with traditional CSS](https://thepracticaldev.s3.amazonaws.com/i/5pfds2n9we0h4zp4b7xr.png)

<figcaption>Traditional CSS button</figcaption>

In functional CSS, i'd to that:

{% gist https://gist.github.com/simonswiss/802f7aa94f8e4ed0eca2313560726909 %}

and

{% gist https://gist.github.com/simonswiss/9a6300a9efe9f8cd9ccaea31037442ad %}

Again, we get the same result:

![Button created with utility classes](https://thepracticaldev.s3.amazonaws.com/i/ozx8eyhtblrh9u4o8sdg.png)

<figcaption>Functional CSS button</figcaption>

> "I still don't get it", you say.

These are two small and purposely naive examples, but hopefully you're able to see a few trends happening here.

In the traditional CSS examples, we have already somehow **repeated ourselves**. Both the warning and button components share similar colours and padding, but we declared these properties twice.

Yes, we could have written the CSS differently. Yes, it doesn't matter much at this scale.

But imagine that you're building 80 components. They will all need background colours, text colours, spacing… and **chances are you'll declare these in CSS for each and every component**.

Want to see how many times you declared, say, a font-size on your website? Go ahead and run it through [http://cssstats.com](http://cssstats.com)

Here are the stats for Medium.com on CSS Stats:

![CSS stats from the Medium.com website](https://thepracticaldev.s3.amazonaws.com/i/lg613qmt9jig76f7rtif.png)

<figcaption>CSS stats for Medium.com from cssstats.com</figcaption>

---

In contrast, the functional CSS warning box and button components use the **same core of CSS classes**, which is only written **once** in CSS. We only had to add the border-radius property.

> The promise of functional CSS is, if you write just enough clever functional CSS classes to mix and match, you should be able to build almost any component without writing new CSS.

This is exactly what toolkits like [basscss](https://basscss.com/) and [tachyons](https://tachyons.io) bring to the table.

## A lot of opinions, not many facts

Functional CSS is guaranteed to trigger a lot of very strong opinions.

If you want a recent example of this, I invite you to read [this post by John Polacek](https://medium.com/@johnpolacek/kiss-my-classname-a-counterpoint-3ca41f0aed1a#.7g6p8h2wu). You'll be able to reverse-engineer your way to the initial post by Adam Morse I have linked to in chapter 1.

For that reason, I have no doubt some of you have stopped reading by now. Some are screaming at their screen:

> "What about semantic classnames?"

> "Your HTML will be polluted with thousands of little classnames and unreadable to other developers!"

> "So, you're saying that if I am writing an unordered list, each `<li>` element needs to have 7 classes applied to it? Are you fo' real?"

One thing I noted during my research on tachyons: there are a lot more opinions out there than there are facts or case studies. A lot of these opinions come from a **gut reaction**, without giving it a real thought.

These are perfectly valid reactions. My initial reaction was the exact same!

## This is why I am writing this series.

I want to share my real-life experience working with functional CSS and going through a complete refactoring with tachyons.

I think I have a little more insights than just gut reactions. I know I made a few key learnings that could be beneficial to other developers.

See you in [chapter 3](https://dev.to/simonswiss/full-re-write-in-10-days-with-tachyons-and-functional-css-a-case-study-part-3-1k4), where we go through the actual refactoring process!