The pre-processor isn’t the problem with your CSS

There has been a lot of bashing on pre-processors lately, and rightfully so. Sort of.

Certainly, these tools, such as SCSS and LESS, can result in excessive bloat and specificity issues in their generated CSS. Lyza Gardner struck the nail on the head in A List Apart this month:

Pre-processors have a way of keeping us at arm’s length from from the CSS we’re building. They put on us a cognitive burden to keep up on what’s evolving in CSS itself along with the tricks we can pull off specific to our pre-processor. Sure, if we’re intrepid, we can keep on top of what comes out the other end. But not everyone does this, and it shows.

But when it comes to pointing the finger, we should be looking at the author, not the tool he uses.

Pre-processors caught on largely because they made it easier to create scalable CSS that paralleled the structure of a pattern library. They made it easier to track variants off of a single element without duplicating any code or requiring additional class names on a single HTML element.

When used correctly, they make coding CSS – and more importantly, maintaining a large CSS code base – so much easier.

To truly take advantage of the strengths of pre-processers, we have to be aware of their limitations and weaknesses, plan accordingly, and think ahead. You could say the same thing about HTML, Javascript, image use, etc. Like any tool, a pre-processor is only as strong as the person who wields it.

@extend is not the problem

One of the biggest gripes about pre-processors is that the use of @extend and mixins result in stylesheets that are bloated and impossible to read. Jed Mao pointed out that the perceived efficiency of using @extend is irrelevant after the file has been gzipped, and certainly its overuse can result in a CSS declaration with too many selectors to make sense of.

However, the use case Jed points out is not representative of the strength of this tool.

@extend is ideal for keeping your CSS DRY. It’s helps to avoid redundancy in HTML or CSS by allowing us to take an atomic approach to writing CSS.

For example, you can write something like this in SCSS…

.button {
    display: inline-block;
    border: 2px solid #333;
    padding: 10px 20px;
    text-decoration: none;
}

.button-primary {
    @extend .button;
    border-color: $primary;
    color: $primary;
}

.button-alert {
    @extend .button;
    border-color: $alert;
    color: $alert;
}

…and get an output like this in CSS:

.button, .button-primary, .button-alert {
  display: inline-block;
  border: 2px solid #333;
  padding: 10px 20px;
  text-decoration: none;
}

.button-primary {
  border-color: blue;
  color: blue;
}

.button-alert {
  border-color: red;
  color: red;
}

No more adding multiple classes to your HTML file to create a primary button. No more scrolling up and up through a looooong CSS file so you can manually add .button-alert to the original .button rule-set. And certainly no more re-writing each of the declarations for a button everytime you define a new style because you can’t remember how much padding you need. (Raise your hand if you’ve been there.)

The addition of variables, placeholder selectors, mixins, maps, efficient nesting, and parent selectors result in endless opportunities to improve the speed and organization of your coding process.

If that ain’t efficient, I don’t know what is.

Plan for success

Problems arise when developers don’t plan ahead for future scalability. This statement could apply to any number of front-end problems, so we shouldn’t be picking on the susceptibility of pre-processors to mismanagement.

Like any tool, a pre-processor is only as strong as the person who wields it.

Developers are designers. They are creating an architecture of content that works in unison to define an experience for an end user. In most cases, the end user may be ourselves, but that doesn’t mean we should forfeit scalability or optimization. Just as we wireframe, prototype, and spec out a design before finalizing the visual layout, we should also create a plan and stick with it for organizing our SASS, LESS, STYLUS, CSS, and other files.

Felicity Evans lays out several examples of best practices to adopt when working with pre-processors:

  • Create a code standard, framework, or styleguide to define how your write your markup, and stick with it.
  • Adopt the inception rule and don’t nest any further than 4 selectors deep
  • Continue to use semantic class names, focusing on function over presentation

And as Roy Tomeij reminds us, know your compiler.

You don’t need to know the internals of Sass to know what will be done to your code. Just open the processed CSS once in a while and see what it looks like. It isn’t rocket science to learn to predict what your Sass code will be compiled too.

There are plenty of resources that can help you test your compiled CSS. Sassmeister is fantastic for SASS(SCSS) and LibSASS. Less PHP has a LESS compiler demo, and I would be curious to know your thoughts on it. Finally, if you work with Stylus, check out their playground as well. If you find yourself writing with pre-processors frequently, and you’re on a mac, you should absolutely purchase Codekit. You won’t look back.

Related