CSS (Cascading Style Sheets) is a styling language that allows web designers and developers to change the look and feel of their HTML markup. It is the language responsible for making the web a user-friendly place (most of the time). It was officially introduced in the mid-1990's and remained relatively unchanged until 2007 when Nathan Weizenbaum and Chris Eppstein embarked on a mission to relieve CSS of what they believed to be its limitations through a pre-processor called SASS. In 2009, another pre-processor called LESS was introduced with very similar features, but it compiled client-side rather than server-side.

The use of a pre-processor meant that developers could do some pretty cool things through the use of:

• Mixins – Reuse sets of properties.
• Parametric mixins – Mixins that take arguments and act like functions.
• Nested Rules – Allow selectors within selectors, which cuts down on repetitive code.
• Operations – Math within CSS.
• Color functions – Brighten or darken your colors.
• Scope – Make local changes to styles.
• Variables – Give nice names to your values and easily change them everywhere.

But as CSS has continued to rapidly evolve over the past several years along with our company and it's best-practices, we have noticed that we really only use a few of these features on a regular basis and no longer believe that the pros outweigh the cons of pre-processing our CSS files. Here's what we no longer find useful and why:

Pre-processing takes time

Here at Dwaiter, we are always looking for new ways to speed up our development cycle. For us, the first step was removing our preferred preprocessor, SASS. Pre-processing adds an unnecessary step and slows down reload time, which is the exact opposite of optimizing our workflow. Then we went a step further by utilizing a browser extension called LiveReload which reloads the page automatically when a change is detected in the CSS file so we never have to unfocus our editor, which dramatically speeds up development time. Speeding up the edit/feedback cycle keeps you in the zone as you develop.

Nested Code

We actually find this feature to be a bit cumbersome primarily because it quickly becomes impossible to see the entire CSS selector/declaration at once, which means lots of potential scrolling if we ever forget what bit of code we are currently working within. Sometimes this approach requires us to override styles we otherwise wouldn't have because they were already inherited in the DOM. Nesting code reduces repetition but often does so at the expense of proper inheritance, alignment, spacing, and legibility which quickly become a burden in more complex style sheets. See the following two code samples:

Using SASS:

body.blog-listing {
.post {
&__meta {
&__date {
color: #808080;

&__divider {
border-left: 1px solid #808080;
margin-left: 10px;
padding-left: 5px;
}
}

&__author {
color: #31A7B5;
}
}

&__content {
margin-bottom: 15px;

&__image,
&__excerpt {
float: left;
}
}
}
}

Using traditional CSS:

body.blog-listing .post__meta__date {
color: #808080;
}

body.blog-listing .post__meta__date__divider {
border-left: 1px solid #808080;
margin-left: 10px;
padding-left: 5px;
}

body.blog-listing .post__meta__author {
color: #31A7B5;
}

body.blog-listing .post__content {
margin-bottom: 15px;
}

body.blog-listing .post__content__image,
body.blog-listing .post__content__excerpt {
float: left;
}

Vendor Prefixes

Vendor prefixes such as -webkit, -moz, and -o were originally introduced so that an individual browser could experiment with new functionality before the official spec was finalized. They were meant to indicate that a feature was experimental (and should not be used in production) so that browsers could change their implementation of a feature without breaking websites. Unfortunately, web developers were so excited about the new features that they used them in production anyway. For this reason, and also because many of these features are in the official spec, browsers have been dropping many of the vendor specific prefixes. This eliminates (most of) the need for a SASS mixin which handled the vendor prefixes for us.

/* SASS Mixin */
#box {
@include transition(opacity 0.2s);
}

/* Standard CSS with vendor prefixes */
#box {
transition: opacity 0.2s;
-webkit-transition: opacity 0.2s;
-moz-transition: opacity 0.2s;
-o-transition: opacity 0.2s;
}

/* Standard CSS without vendor prefixes */
#box {
transition: opacity 0.2s;
}

Caniuse.com showing that vendor prefixes for border-radius are no longer needed.

Variables

Most commonly, we find ourselves using SASS variables to define colors so we don't have to memorize the HEX values or continue grabbing them from a PSD file. However, with the introduction and now widespread support of CSS variables, a preprocessor is no longer needed to use this feature.

/* DECLARE VARIABLES IN SASS */

$orange: #F79E1F;
$blue: #457F98;
$green: #2F765C;
$red: #D02E2E;
$purple: #AD28C9;
$darkGrey: #1A1A1A;
$white: #FFFFFF;

/* DECLARE VARIABLES WITH CSS VARIABLES */

:root {
--orange: #F79E1F;
--blue: #457F98;
--green: #2F765C;
--red: #D02E2E;
--purple: #AD28C9;
--dark-grey: #1A1A1A;
--white: #FFFFFF;
}

In Conclusion

We do not find these pre-processors useful based on our common CSS needs, but this may not be true for every developer or for every company. SASS and LESS do have their benefits, but we hope that after reading about our decision to revert back to vanilla CSS that you will consider how much you really benefit from using these tools.