Full re-write in 10 days with tachyons and functional CSS: A case study (Part 1)
Tags: css, utilityfirst, atomic, bem
Published: 2019-08-02 11:01:14

---
title: Full re-write in 10 days with tachyons and functional CSS: A case study (Part 1)
published: true
description: This is the beginning of a 4-post series, taking you through a website refactoring process using tachyons, a functional CSS toolkit that is guaranteed to trigger very strong opinions [insert Dave Rupert's hot drama soundboard effect].
tags: css, utility-first, atomic, BEM
canonical_url: https://medium.com/hackernoon/full-re-write-with-tachyons-and-functional-css-a-case-study-part-1-635ccb5fb00b?
---

---

### This is the beginning of a 4-post series, taking you through a website refactoring process using [tachyons](https://tachyons.io), a functional CSS toolkit that is guaranteed to trigger very strong opinions [insert Dave Rupert's hot drama soundboard effect].

### On the menu

1. **Why re-write in the first place?** (you are here! 👋)
2. [What even is functional CSS?](https://dev.to/simonswiss/full-re-write-in-10-days-with-tachyons-and-functional-css-a-case-study-part-2-2opg)
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)

---

**The series is ported from Medium (Hackernoon publication), and was originally written in February 2017.**

The website in question is SocietyOne, an Australian marketplace lending company where I (used to) work as the front-end lead.


Let's begin!

---

## Chapter 1: Why re-write in the first place?

The marketplace lending industry is fairly new and things are moving fast.

We're a very small team. We designed and developed our "new" website about two years ago, and have been maintaining and evolving the codebase in a very iterative process.

We planned things carefully. Adopted the BEM methodology to organise our styles. Things were working great for us.

We were writing beautiful, clean modules. We had a good understanding of our codebase. Up to a certain point.

I love BEM. I think it's a great way to organise your CSS and does a good job at keeping specificity relatively low. What BEM (and most other CSS architecture methodologies) doesn't really help with is dealing with **accumulating technical debt**.

Our growing company went through a lot of churn. New people, new opinions, new strategies. This generates a lot of minor - and major - change requests. This phenomenon, commonly known as BAU (business as usual), is one of the biggest drivers of technical debt in a codebase.

## The Start of the End

BAU requests often coming with a "can we have it done today" deadline, as a developer you run a high risk of reaching out for questionable techniques at some point.

It might be an extra class at the bottom of a stylesheet, or a copy/paste of a module with a few tweaks here and there instead of carefully crafted "BEM modifiers".

Before you know it, you're considering introducing a [shame.css](https://csswizardry.com/2013/04/shame-css/) file in your repo. Dare I say, you may even reach for an *inline-style hack*. 😱
And then, things get out of hands.

It doesn't take many hotfix hacks to throw a huge spanner in your beautiful CSS wheel. And as real-life BAU requests continue, you can only witness your handle on the codebase slip away further and further. 😓

## When things reach a tipping point

In the weeks leading up to Christmas 2016, I felt like things were reaching a tipping point. Tech debt was becoming a serious problem, and there was no sign of BAU slowing down. Quite the opposite, actually.

I was losing a lot of sleep over this increasingly worrying situation. I remember being close to the edge of the "burnout cliff". Dangerously close.

## What now?

Something needed to happen. *Some* thing.

One day, totally out of the blue, my colleague showed me that intriguing thing he stumbled upon, called tachyons.

> Looking back, this very moment may have played a huge role in preserving my mental health.

I had never heard of tachyons before. I had a look. My initial thought was: "Meh, look at all these classes in the HTML. Ugh". I moved on.

A lot of people - if not everyone - have the exact same initial thought.

And they **move on**.

A couple of days later, I read this [spectacular blog post by Adam Morse](https://mrmrs.cc/writing/scalable-css/) (the creator of tachyons). That article resonated with me so much that I decided to give that tachyons thing a second look.

The more I thought about this functional CSS approach, the more it made sense. My head started to buzz with excitement and hope.

In the [next chapter](https://dev.to/simonswiss/full-re-write-in-10-days-with-tachyons-and-functional-css-a-case-study-part-2-2opg), I'll show you why!