DEV Community: Simon Vrachliotis 🏄🏀💻😍

Full re-write in 10 days with tachyons and functional CSS: A case study (Part 4)

Simon Vrachliotis 🏄🏀💻😍 — Fri, 02 Aug 2019 22:20:48 +0000

This is the final chapter of a 4-post series, taking you through a website refactoring process using tachyons.

On the menu

Why re-write in the first place?
What even is functional CSS?
The refactoring process, step by step
The aftermath: key learnings and recommendations (you are here! 👋)

Chapter 4: The aftermath - key learnings and recommendation

In this final post, I try to share some insights about things I have learned throughout the refactoring process. Things I learned while working with functional CSS and hanging around this specific ecosystem.

I'll start by addressing a few doubts or pain points that people seem to have quite often.

1. How do you deal with the repeating classes and overwhelming, "ugly" HTML markup?

Nobody likes to type the same classes over and over, or copy/paste things around. Besides being time consuming, it's the opposite of being DRY. It can put you in a world of pain when you decide to make some global changes to your UI.

Template abstractions to the rescue.

When working with functional CSS, I strongly recommend you bring a templating language of some kind to your workflow. It makes a world of difference.

As soon as you find a repetitive class pattern - and trust me, you will! - abstract it away in a variable. I like to refer to this process as the creation of "class combo" helpers.

Show me how!

Let's take some code straight from the tachyons.io component library section.

The component in question is a "contact list" and looks like so:

Contact List from the tachyons component library

Let's have a look at the raw HTML + tachyons markup. Yes, it may look ugly to you:

Whoaaaa. My eyes!!

There are a lot of classes here. Trust me, there can be many more, depending on what you're building.

Assuming we may use this component in multiple places across our project, we have many good reasons to want to make this HTML cleaner and modular.

Building class combos.

Time to abstract away some of that repetitive markup.

You can do this with any templating language of your choice. In this case, I'll use Twig, since this was the language used during the refactoring. If you don't know Twig, you should still be okay to follow.

Don't worry too much about the syntax, focus on the concepts.

Deciding what classes to abstract away is a whole other topic, which I'll touch on later. For now we'll just take the relatively long class combinations and store them within a combo object:

This allows us to output the long string wherever we want by reaching for the object property, like so:

<li class="{{ combo.listItem }}">

Let's implement that in our HTML:

What?! Isn't that besides the point? You just lost the declarative aspect of functional CSS!

Hold your thoughts for a second. Let me clean this code up a bit more and then address this very valid point.

This next step is not related to functional CSS, but is a good idea to implement whenever working with repeating blocks of HTML.

We can clearly see a repeating pattern within each <li> element. Let's fix that by first extracting the data from the markup.

I'll set an array of contacts like so:

We can now rewrite our entire component in a pretty compelling loop that outputs one block of HTML for each index in the contacts array, making the code much tighter, readable:

Well done, champ. You've just recreated semantic classes. Way to chase your own tail! 😒

You are right. We went full cycle. Why not just write semantic class names in the first place?

Well, while the HTML now looks somewhat similar to what you would get with a regular CSS approach, there is a huge difference in the way the styles are applied.

Instead of styling my listItem with its own CSS declarations, the styles are composed from multiple helper classes. I can create dozens, hundreds of components with this method, without having to write a single extra line of CSS.

This is still functional CSS under the hood.

Trade-offs, again.

This technique is definitely not a silver bullet. Like everything you do in web development, you need to be evaluating trade-offs and see what works best for you.

Here's a mini break down of trade-offs I can think of with this abstraction technique:

Pros

makes code cleaner, faster to write
improve consistency, using same styling in multiple places
greatly improves ease of global modifications. Change in one place, update everywhere

Cons

takes away the declarative nature of style classes
somewhat couples classes together, killing some of the "one-thing-only" ideology (I learned the hard way!)

Lesson learned with class combo abstraction

I fell in love with this technique. It gave me the power of building web components that are self-contained, highly reusable and consistent.

In the excitement, I possibly went a bit overboard, and got a bit too "abstraction-happy".

Looking back, here's a rule of thumb that could be very useful to you, if you're going down that route:

Don't abstract the outside vertical spacing!

In other words, feel free to abstract away the background-colour, border-radius, padding of a given module, but leave things like margin-bottom out of the equation.

Same for a headline. Abstract things like font-size, line-height but don't you touch the vertical padding / margin around it.

See my example below if this is not clear.

What about consistent vertical rhythm?

Even if you feel like the bottom margin is part of the module and should be consistently applied, it somehow belongs "outside" the module. And should be treated separately.

You'll run into edge cases where you need to display the same module without a bottom margin, because of the specific context you're trying to display it in.

You could override your margins by applying different margins before your combo, but that's starting to get messy.

This lead me to a fair amount of refactoring. I ended up removing vertical spacing from my go-to style combos, and started applying them in addition to the class combo.

Here's what it looks like

In the below example, the margin-top and margin-bottom are "hard-coded" within the combo:

Instead, I suggest you leave these margins outside of the combo:

That's a good example of a good trade-off balance. We keep a degree of modularity / composition, while abstracting away the majority of the repeating classes. I could leverage my combo class in two different scenarios, and it's quite readable and declarative.

2. How do you customise tachyons?

There is an important concept to grasp: tachyons is not an "all or nothing" solution. It's not a UI framework like Bootstrap or Foundation.

Tachyons is a systematic, consistent methodology to write functional CSS classes. In that sense, it is virtually infinitely flexible.

Tachyons proposes a consistent naming convention, and encourages you to follow the lead.

Here are a two important things you need to know when working with tachyons:

You can and should turn off the parts you don't need, extend the parts you want to push further.
There is no right or wrong way of extending tachyons - the key is to understand the implications of whatever method you choose to adopt.

The way I did it.

After some good amount of thinking and tinkering, I decided to not touch any of the core tachyons files. Even if the author of the library invites you to dig into it and "make it your own".

Why? This makes sure implementing updates is never an issue.

Instead, I opted to create a tachyons-extend folder that I load after the core tachyons modules. Here's what my Sass pipeline looks like (I am using the tachyons-sass version of the toolkit, which also exists in different flavours).

The pipeline setup. I never customise the core tachyons files.

In tachyons-extend, I can write brand new tachyons-like modules for areas of the CSS spec that are not (yet) covered by the toolkit.

Extending a module

In some cases, I just want to extend a core module. An example is the max-widths module, where we needed more flexibility.

I created a file with the same name in my tachyons-extend folder, and just added more declarations following the same naming convention:

Extending the `max-widths` module.

As a result, I can access any class of the core max-widths module, as well as the extensions I created, without ever touching the core code.

Rewriting a module

Sometimes, a specific module is needed doesn't really do what you need, or does too much. Extending on top of it doesn't make sense in that context.

When that happens, I usually comment that module out in the core pipeline, and recreate a custom version of it in my extend folder.

I have done this for the box-shadows module - which styles I mostly didn't plan to use, but still needed box-shadow helpers:

The core `box-shadows` module, not needed.

The module is commented out in the core pipeline.

A custom `tachyons-extend/box-shadow` module is created.

Again, I modify the behaviour / usability of tachyons, without touching any of the core files. The only modification I do is comment out some partials in the master tachyons file.

3. What about good ol' regular, non-functional CSS?

This is one thing that often confuses people. There are many discussions about this around functional CSS.

Let's make it clear: functional CSS does not prevent you from writing regular CSS in parallel.

It is absolutely okay to write non-functional CSS styles. Actually, there will probably be places where you need to.

Tachyons doesn't really impose anything on you. All it tries to do is give you ways to avoid repetition and limit the creation of custom CSS to a very small minimum.

Write your own CSS when needed. But keep this in mind:

Specificity is almost non-existant in functional CSS. By design. It's a feature of the system.

But is also has an implication. You need to think critically before write any custom CSS. The minute you bring a degree of specificity, you'll start overriding your functional classes.

If you know exactly what you're doing and why you want global styles in specific areas, by all means go ahead.

It's up to you to find the right balance of global CSS and functional classes that works best with your system. Trade-offs, again.

Pfeeew, that was a lot! Hopefully you're not asleep yet.

We're almost there. The last thing I want to share with you is answering the two questions: Would you do it all over again? What would you do differently?

Would I do it all over again?

To say the least, this refactoring was a bit of a gamble.

I did spend some time reasoning about the benefits of using tachyons before going ahead, but certainly not long enough to foresee some major problems it might lead us to.

As mentioned in my introduction, refactoring was not an option. There is only so much a human brain can cope with.

Would I do it again? Absolutely. I am yet to hit a wall or reach a point where I see my handle on the codebase slip away. I feel like I can take any BAU or new design and implement it very quickly without adding much complexity, if any.

Learning tachyons classes can be done in a weekend. Once you master them, building stuff is so straightforward it straight-up feels like a joke. Bringing a team up to speed with a tachyons codebase is as smooth as it can get.

What would I do differently the second time?

Here's an important bit of advice for you. This is probably the biggest mistake I made in the entire process:

Build mobile-first components, from the get go. Don't wait.

When working with functional CSS, you're spending 99% of your time in HTML. You're productivity is incredibly high, because your brain doesn't need to handle any context switching between markup and stylesheet.

You stay in the same file, lock in and get stuff done.

You're working so fast, it becomes far too easy to get caught in the "let's build it on desktop first, then go through it again at different breakpoints" approach.

Making this mistake lead me to a fair amount of time going through the entire website again on mobile, doing tweaks everywhere.

And here's the real twist: tachyons is written in a mobile-first architecture. Base class names apply to everything - and mobile by default. Extended, responsive class names for larger screens override the base classes, by design.

They are not more specific, they are just loaded after the base classes in each module, and therefore win the battle by "just enough".

Why is this such a big deal?

Say you've used a consistent vertical spacing of mv5 across the site, between sections.

The mv5 class applies vertical margins like so:

.mv5 {
    margin-top: 8rem;
    margin-bottom: 8rem;
}

You build the whole desktop site thinking it's a good vertical rhythm base for your project.

Later, you look at it on mobile and realise that in this context, this vertical spacing is way too big.

The thing is you cannot override that class with a mobile-specific class. You need to do it the other way around (there are valid reasons for that).

You need to transform the classes in all the places where you used mv5 to something that declares the mobile spacing first, then modifies that spacing on bigger screens.

You go from:

<section class="mv5">
    ...
</section>

to:

<section class="mv4 mv5-ns">
    ...
</section>

We now apply a vertical margin of level 4 on the modular scale for mobile, and level 5 for the not-small breakpoint and up.

The CSS output would be equivalent to this:

section {
    margin-top: 4rem;
    margin-bottom: 4rem;
}
@media(min-width: 40rem) {  
    section {
        margin-top: 8rem;
        margin-bottom: 8rem;
    }
}

Such a small change doesn't seem like a big deal. At large scale, it will be.

If you effectively wrote the entire desktop site in mobile classes, you're up for some refactoring to transform your code to responsive.

Again, the use of templates and re-usable components can limit the damage of this mistake to a minimum.

But here's a good final lesson. Think mobile-first, right away.

Closing words

If you've been reading all along up to this point, congratulations and thank you!

I hope that throughout this series, I was able to make a case for the valid benefits of using a library like tachyons.

If anything, take this as a real-life case study of what I'd call a successful website refactoring. Ever since we moved to tachyons, I feel like I have a real cognitive grasp on the codebase, and am able to handle day-to-day business requests and changes with incredible ease.

Functional CSS is not a fit for every taste and every team. In our particular context, I personally found it to be bringing an incredible amount of benefits, without showing any signs of major drawbacks.

If you're aware of a huge drawback of functional CSS I failed to discover up to now, I'd love to hear about it.

Let's start a discussion!

Full re-write in 10 days with tachyons and functional CSS: A case study (Part 3)

Simon Vrachliotis 🏄🏀💻😍 — Fri, 02 Aug 2019 21:36:27 +0000

This is the third chapter of a 4-post series, taking you through a website refactoring process using tachyons. It's about time to get started with this re-write!

On the menu

Why re-write in the first place?
What even is functional CSS?
The refactoring process, step by step (you are here! 👋)
The aftermath: key learnings and recommendations

Chapter 3: The refactoring process, step by step.

Ok. Here we are, finally.

Well, almost. Let me start by setting the stage here.

We're a couple of days before Christmas. Everyone is leaving on holiday. I have been demanding a two-week window to do some major refactoring, and it looks like the Christmas and New Year break is my "one shot" to get it done.

I get a chance to get in the zone, get some isolation and focus on that one task only, while the office (and BAU) is in shutdown mode.

At this point, I don't have a clear idea of how much I'll be able to refactor over the break. I've done enough research and reasoning around tachyons to know it can solve our tech debt problems. I just don't know how complex the transition from our current CSS to the new system will be. How long it's going to take.

A very nerdy holiday season

I am sitting in the car with my laptop.

My wife is driving us and our two young kids to Mudgee, a country town 5 hours inland from Sydney, where we're starting a 6-week camping journey throughout New South Wales.

You got that right. I'll be conducting my entire refactoring process while being on the road, in some areas with little to no internet.

Sounds like a plan!

My "on the road" office.

Out of topic, but this reminds me of that controversial tweet that came out. I giggled as I read it in the middle of a major Christmas Day refactoring session:

Joe McCann

@joemccann

The best software developers I know are always hacking over the holidays.

True story.

18:50 PM - 24 Dec 2016

131 391

I certainly don't pretend to be the best developer. Joe McCann doesn't know me. But I was sure as heck hacking over the holidays! 😂

And, here we go.

I'll break the process down in a few steps or milestones I went through, in a chronological way.

The starting point

Our "legacy" CSS is composed of the Foundation framework and a large amount of custom BEM modules.

Our website is running on the beautiful CraftCMS, which uses Twig as a templating engine. More later on why using a templating language matters.

Getting started is a tricky one. The website needs to be operational when office re-opens, otherwise BAU will take over again, and my tachyons GIT branch will never see the light.

How do I gradually implement tachyons without putting the website in "demolition site" mode?

Step1 : tachyons as "sugar on top"

After some thinking and discussing in the tachyons slack, I decide to simply load tachyons at the very end of my stylesheet.

This allows me to use a few tachyons helper classes for padding, color, etc, without running the risk of breaking anything else.

If I don't use the helper classes, nothing happens. It feels pretty safe. I can get a feel for tachyons without taking much of a gamble.

Within an hour of work, I am blown away. I am able to remove huge chunks of legacy CSS and replace it with simple tachyons classes. Removing CSS is one of the hardest thing to do in web development, and I am moving incredibly fast. This is truly remarkable. I am giggling.

I try to explain this to my non-dev wife - who is still driving - but she doesn't really get a sense of why it's such a big deal. 😂

It's so easy, it almost feels like a joke.

I take any given BEM module partial. I find the HTML template for this module, and just rebuild it in tachyons.

I comment out an entire custom CSS partial and move onto the next one. It still works. This is ridiculous.

I was expecting to just replace some margins, padding, font-sizes and weighs, but here I am, writing entirely tachyons-powered components. With incredible ease.

Enjoy it while it lasts.

At some point, I notice that my progress will eventually slow down.

I start to notice more and more places where my tachyons classes don't work. Buttons have unexpected hover states, spacing is a bit off.

I realise that I am trying to fight some Foundation classes, that have more specificity than tachyons and therefore win.

If I try to comment out Foundation, I can see some of my nice tachyons modules look weird. They were inheriting some styles from Foundation, and don't look the same without them.

First lesson learned. If you plan to remove the underlying CSS framework at some point - which is my plan - don't wait too long before you do it.

Which leads me to step 2.

Step 2: Going "all-out"

It's still very early in the first week. I have plenty of time. I decide to create a new branch called kill-foundation in which I comment out everything.

I want to see what things will really look like when i get rid of all the legacy CSS.

But first, let me say this: working while camping and watching your family enjoy a holiday, is a beautiful thing. I highly recommend you try it if you have a chance.

Simon Vrachliotis 🏄🏀💻😍

@simonswiss

Three hours into my work day, my 4-year old son brings me a biscuit, an apple and three shells from the beach. 😍🙌 #remotework #camping #kids

00:13 AM - 27 Dec 2016

2 14

Okay, back to our refactoring.

So, I go ahead and comment out all the CSS partials except tachyons.

And I watch the website explode.

"Hey, it's not that bad, actually!"

Sure, the website is broken as hell. What do you expect, I just removed almost 200kb of custom CSS.

But, it's not that bad. Ironically, some parts of the typography and vertical rhythm feel more consistent. This tells me something about tech debt and custom CSS declarations all over the place. 😂

Grid layouts are the most obvious

The first thing I decide to fix - because it's by far the most obvious - is all the places were we relied on Foundation's columns.

While tachyons is perfectly capable of handling grids in many different ways, I make the call to use another library called Flexboxgrid.

Flexboxgrid does one thing: it provides you with a super versatile grid system using, well... flexbox (who would have guessed!). If you're familiar with bootstrap's classes, you're going to like it.

Flexboxgrid has a small footprint and makes re-building the grid layouts a breeze. In my books, and taking my designer colleague in consideration, it definitely warrants the addition of 14kb (non g-zipped) to the build.

One module at a time.

Once the grid layouts are back in place, I feel very confident. I look at sections of the site and know exactly how to build them in tachyons.

So I get to work, starting with the homepage.

And I complete the homepage within a couple of hours. Boom 💥.

Getting excited in slack

If I still had any doubt that I could pull off the entire rebuild over the holiday, I am now very confident that the site will be ready when I come back in the office.

Confidence is rapidly growing

I still can't get over how fast building modules becomes once you're fluent in tachyons. It's mindblowing. And you get this incredible sense that nothing is getting more complex as you move forward.

It all becomes predictable, and that's a very empowering feeling.

And then, one day..

On the 4th of January 2017, 10 days after Christmas, I pushed the new build to our pre-prod environment.

I did it! With a fair bit of extra time left, too.

The verdict

In the 4th and final chapter, we'll dive a bit deeper in tachyons-specific learnings and recommendations.

For now, let's make a few general observations.

1. Not a 100% design match

The new version of the website is not a 100% match of the legacy site. Nor did it ever pretend to be.

The main purpose of the re-build was to get rid of tech debt. I tried to make the site look the same, while trying to standardise some components to a more consistent overall look and feel.

In some places, the site is not as good as it used to be. But in many places, it's better.

Overall, it definitely needs a polish. While I have an eye for design, I don't come remotely close to skills of SocietyOne's very own design director (and close friend), Mr Matt Barron.

edit: fun fact, Matt and I are now colleagues again at Thinkmill 🙌

2. Significantly less buggy

The whole thing feels so much more stable. I cannot stress this enough.

Immutable, single-purpose functional CSS classes mean that if you do
things right, there is literally no risk of accidental overrides.

3. Onboarding team members is easy

One of the first assumption people do about tachyons is that it's going to be impossible for anyone else to work on your code, unless they learn tachyons.

Well, that's true. And that's true for any codebase. Thinking you can jump in any codebase and just know what to do without having to learn the system is.. delusional.

I strongly disagree to this argument. And I'm Swiss - we tend to remain neutral most of the time.

While I concede that templates look confusing at first, you see things with a completely different angle once you become fluent with the tachyons syntax.

It doesn't take long to memorise tachyons classes. Trust me, it would take much longer for you to make sense of all the custom BEM modules we had in place before that.

4. Removed context switching makes you SO fast

When working with functional CSS, the HTML is very declarative and self sufficient. It tells you exactly how things are going to look, without having to lookup CSS stylesheets to figure it out.

Being able to work in one file without ever switching context in your brain yields incredible gains in productivity.

You hear similar comments from React or Vue developers. They love working within one self contained component file. They call it the real separation of concerns, and not separation of languages.

5. Huge reduction in CSS bundle

Without worrying about performance at all, the CSS bundle when first pushing to pre-prod turned out to be less than 50% of the original bundle size.

Simon Vrachliotis 🏄🏀💻😍

@simonswiss

Two weeks ago, I started refactoring the @mysocietyone website with @tachyons_css to cull CSS tech debt. Not finished yet, but great stats!🎉

00:45 AM - 04 Jan 2017

3 12

6. Cognitive load is ridiculously low

I feel like no BAU can stop us now.

Put it this way - tachyons as a toolkit for BAU lets you do things that are as easy as slapping inline-styles, but are fundamentally different in the impact they have on the rest of your codebase.

I'm sure you've all been there: a stakeholder (or client) wants to take a section of the site and move it up higher on the page.

It sounds like a "minor change" for some people. As a designer/developer, though, you see some of the issues it can brings to the mix.

Maybe the section had a green background. You've been asked to move it right under another green background section. It doesn't work well at all there. Spacing is completely off now, and the margin-top needs to go away.

In these types of situation, it could be easy to be tempted to just slam an inline-style like <div style="margin-top: 0;"> and call it a day.

Functional CSS is somewhat similar (but completely different, although that point is often misunderstood) to inline-styles. In that sense, you can apply the same effect to your section with <div class="mt0"> without any of the negative effects of applying inline-styles.

If you still need some margin top on mobile, but not on larger screens, you could do <div class="mt2 mt0-ns">.

Good luck doing that with *inline-*styles.

7. Functional CSS enforces being DRY and modular

I heard many people claim that functional CSS is for lazy people, or people who don't understand CSS enough to use it well.

I couldn't disagree more.

The way I see it, functional CSS forces you to think "modularity" when writing your HTML. No one enjoys copying and pasting the same classes over and over in an HTML document.

To avoid this, you need to step up your "architecture" game and think of ways to make your HTML components re-usable as much as possible.

Things like storing content in a data array, writing loops to output a repeating block of HTML have a huge impact when it comes to maintaining your code.

Tachyons has definitely made me dig deeper into modular templating techniques. The web is pointing towards web components from all angles. It's good to embrace this mindset.

Extracting your content from your markup, making it as much back-end agnostic as possible, is a good thing. It makes you a better developer.
Functional CSS makes you think in components, systems. Not pages.

Did I just sound like Brad Frost?

So what, functional CSS has no drawbacks?

Functional CSS is probably not perfect. It's most definitely not to the taste of everybody.

The initial negative reactions on the ugly looking HTML, loss of semantic classes are common, because they are real facts.

You can only see past these reactions if you give it some thought and evaluate trade-offs.

Being a web developer is all about evaluating trade-offs. How much benefits do you need to get from a system or methodology to overcome the perceived negatives?

If I had to summarise my experience with functional CSS in one paragraph, it would be this:

"The benefits I get from using functional CSS, in terms of reduced cognitive load, self-describing declarative HTML markup and huge productivity boost, are simply amazing. They overcome by far the few negatives that this approach brings to the mix. I'd take that trade-off any day of the week."

And I did.

See you in the final chapter for some tachyons-specific observations, suggestions and lessons learned!

Full re-write in 10 days with tachyons and functional CSS: A case study (Part 2)

Simon Vrachliotis 🏄🏀💻😍 — Fri, 02 Aug 2019 20:59:40 +0000

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

Why re-write in the first place?
What even is functional CSS? (you are here! 👋)
The refactoring process, step by step
The aftermath: key learnings and recommendations

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

In your CSS file, you could do this:

You'd end up with something like this:

Traditional CSS warning box

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:

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

The result looks exactly the same:

Functional CSS warning box

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:

and

We'd get this:

Traditional CSS button

In functional CSS, i'd to that:

and

Again, we get the same result:

Functional CSS button

"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

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

CSS stats for Medium.com from cssstats.com

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 and tachyons 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. 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, where we go through the actual refactoring process!

Full re-write in 10 days with tachyons and functional CSS: A case study (Part 1)

Simon Vrachliotis 🏄🏀💻😍 — Fri, 02 Aug 2019 11:01:14 +0000

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.

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 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 (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!