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].
On the menu
- Why re-write in the first place? (you are here! 👋)
- What even is functional CSS?
- The refactoring process, step by step
- The aftermath: key learnings and recommendations
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.
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 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.
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 (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, I'll show you why!
Top comments (0)