Newer Post

X-Outpost: 2016 recap

Older Post

Introducing Paths: Learn new Skills, Faster

FORC: The Fear of Removing CSS

A little while ago I had a magical moment.

We were building a web application and the product team had decided to phase out a certain feature. This meant that one of the UI components we had built was no longer needed.

From the beginning of the project we had put some thought into a modular architecture, and so all of the code for this component was nicely contained within a single directory. Now that it wasn't being used anywhere, we could safely delete the entire thing.

The surprise to me came with the realisation that this directory also contained a CSS file with styles for the component. I was surprised because all of my developer-instincts were flashing danger signs. And yet there was no danger at all. 100-odd lines of CSS, deleted in the twinkle of an eye.

Like many, I had become accustomed to thinking that CSS is easy to add, and hard to delete. I worked on several projects over the years where old CSS was seldom removed, out of a fear of breaking something. And often, this fear was a rational one. It became simpler just to leave the old code in place and work around it.

Uh, I wouldn't take it down if I were you, it's a load bearing poster

So this new experience made me wonder: what made it so easy to delete CSS this time?

In my recent talk At Least 6 Ways to Win with CSS Modules (at the wonderful CSSConf AU), I touched on this topic and some of the things that can help us get over this fear. It's not a feature unique to CSS Modules, but I recommend that using CSS Modules in one of your projects is a great way to discover these ideas for yourself.

So why is removing CSS so difficult? Why do so many of us relate to past experiences of this fear?

I think it comes down to a simple rule: you can only safely delete something if you know all of the places that depend on it.

At this moment, when we can confirm without a doubt that our code is not a dependency of any other part of the system, deleting becomes a no-brainer.

However when dealing with traditional forms of CSS, we meet a few hurdles. Think about this CSS code:

div {  
  line-height: 1.1;

When this is in your stylesheet, every single <div> element will be affected. In other words, there is a dependency between these 3 lines and every <div>.

I'm not at all saying "don't write code like this" - it can be very useful when you're setting up theme styles, for example. But do be aware of the costs. If you ever want to remove these 3 lines of code, you'll probably have a very large number of places to check, and finding them all may not be easy.

So we may decide that this code is worthwhile for theme styles, but when we want to describe discreet UI components we clearly want something much more precisely targeted.

Here are some of the ways that CSS Modules helps us, as described in the talk:

  • we can use simple classnames that are also very precise, because all classnames are automatically namespaced to their module,
  • all of our CSS files can be considered as nodes within a dependency tree, making it very easy to see (and compute!) where the dependencies are,
  • we get a tangible API between CSS and the DOM, rather than the old way of linking HTML and CSS via arbitrary strings.

So if you want to defeat FORC and overcome your fear of removing CSS, think about using CSS Modules, or some other technique (eg. many people achieve this with BEM) that allows you to encode explicit dependencies between CSS and the rest of the system.

And then you too will experience the magical moment of deleting CSS.

We'll help you unleash.

Join the 20,000 developers who subscribe to our newsletter.

Scale your
Development team

We help you execute projects by providing trusted developers who can join your team and immediately start delivering high-quality code.

Hire X-Team
code, css