Do I Need To Start Using CSS Preprocessors?

A Not So Deep Dive

Stepping into the world of front end web development, I am repeatedly in awe, as well as, excited about how much there is to explore, and play around with. Following on from my quest to understand JavaScript transpilers, my instinct to ‘run before I walk’ led me to CSS preprocessors.

Based on first impressions, preprocessors did not grow on people quickly. For those who would like some clarity — CSS preprocessors compile code from a language to simple vanilla CSS. CSS, for most, is limited in functionality. Its limitations include not being able to use variables or functions, and that means having to write a lot of code again and again. It essentially violates the programming principle of DRY (Don’t Repeat Yourself) and leads to code which is verbose and WET (waste everyone’s time).

Preprocessors solve this need for more functionality and add to what can be accomplished with CSS. This article is not meant to be an extensive guide to them but more of a primer, giving a quick view into what preprocessors are all about.

So, should you start using preprocessors?

The most simple argument for them is that preprocessors can make CSS code more organized. With the power that comes from using variables and functions, lines can be shaved off CSS code and that means more readable code. This means that maintaining code will also be easier and in the long run it will be easier to edit.

CSS preprocessors also provide the option of using mixins. Mixins are like classes that can be reused by other classes without having to be a parent class for the latter or without having to be inherited. Wynn Netherland did a post on using mixins vs having multiple classes. See that to get a better idea of how mixins promote code reusability and promote cleaner and DRY-er code.

To give a more practical idea about what CSS preprocessors can do, here are some popular examples:

Sass

That’s syntactically awesome style sheets. Or also called ‘CSS with superpowers’. Sass can be written either in the ‘indented’ syntax, or it can be written in the conventional CSS syntax, with curly braces, which is referred to as ‘SCSS’. The latter is more popular because it is more in line with the syntax of vanilla CSS. Whether choosing the ‘Sass’ syntax or the ‘SCSS’ syntax, both are syntactically awesome stylesheets in the end, and possess some nifty features. Sass supports nested selectors. This means that if, say, a certain class is used repeatedly then the unique elements can be nested inside it’s indentation.

What it means is that this CSS code

Can be written like this in Sass

More than anything, Sass makes CSS code more readable and easier to maintain. It is worth noting that Ruby is a prerequisite for using Sass. This means Ruby will have to be installed on the development machine. PHP and C implementations also exist, the latter being LibSass. LibSass is particularly popular for its characteristics of being fast, portable and the ability to integrate with a variety of platforms. Dart Sass has also been introduced recently.

Less

Less is another stylesheet language that compiles to CSS. While it was initially written in Ruby, that has since been replaced by JavaScript. Like Ruby is required for Sass, Less runs inside Node.js. Less works as a JavaScript library and can run on both client as well as server side. No new syntax is needed for Less, which is a plus for those who don’t want to stay far from CSS. It extends the functionality of CSS to provide all the common preprocessor features — nesting, variables, basic type functions etc. An example of how functions can work with colors and mathematical operations is:

Here, width is converted from 0.5 to 50% using the percentage operation. Saturation of the base is increased by 5%, while background color has been set to 25% lightness of the base color and spun by 8 degrees.

Another popular characteristic is the IDE support for Less in Visual Studio, WebStorm and VS Code. On the downside, Less has no support for custom functions and the use of ‘@’ to declare variables, instead of the CSS convention for accessing keyframes, can add some confusion to the code.

Stylus

Stylus in influenced by both Sass and Less. It is built on JADE and Node.js. Stylus does away with a lot of syntactical elements, such as braces, colons, semi-colons. Which is why CSS like this:

Ends up looking like this:

The benefit of deriving inspiration from Less and Sass is that Stylus has features influenced by both, thereby making it a powerful feature set. This includes taking properties from parents and inserting them into children, letting a CSS block determine what level it is at (such as root or not), overloading an array — in terms of number of variables passed, and converting files to base64.

Final Thoughts

Even after CSS preprocessors started gaining adoption, there were arguments against them. But for those who have adopted them, there has been acknowledgment of the fact that preprocessors add depth to what CSS can be used for. The functionality that comes with If/Else statements and loops can aid in adding more power to a web page.

Bootstrap works with Less, and while I am not saying that is direct example of CSS preprocessor power, it does give an idea about the degree to which CSS preprocessors have entered the web development sphere. (Update: Bootstrap also has an official Sass port which is maintained as a separate repository.)

Major enterprises like Facebook noticed the difficulty in maintaining large codebases of CSS, and do use CSS tools to solve their problems. Compass, a CSS authoring framework is built on Sass, is in turn used on sites like LinkedIn. The misconceptions around preprocessors such as needing a Ruby backend for using Sass, or that the prerequisites are tedious to install are often misguided.