Which is the best CSS preprocessor?

[Rss Bot 1]

There are a number of CSS preprocessors on the market. You’ve probably heard of Less and Sass (if not, take a look at our article on what is Sass?), but there are a number of other options that might be better suited to your needs. Here, we take a closer look at all the different preprocessor around, and the pros and cons of each one. Use the quick links on the right to jump to a particular section.

A word of caution first. Back in 2007 Jon Christopher wrote a blog post entitled Please do not use CSS frameworks, and a lot of his comments stand true today. “A big problem with frameworks is when up-and-coming developers attach themselves to a framework as opposed to the underlying code itself. The knowledge gained in this case surrounds a specific framework, which severely limits the developer.” While preprocessors can undoubtedly make your life easier, there is always a danger that relying on a framework will reduce your understanding of the core language underneath.

01. Sass

“Sass is the most mature, stable, and powerful professional grade CSS extension language in the world”. That comes from the makers, but it’s pretty hard to contest. For over 11 years, the team behind Sass have worked diligently to build a preprocessor that is feature-rich, has a large community to support, and develop it and its users, and has been adopted by some of the biggest names in the industry. It offers by far the most engaged community, with forums, dedicated sites, and tutorials on every major teaching platform for code – take a look at The Sass Way in particular.

Sass is built on Ruby and offers two different syntax types depending on the user’s preference. Sass doesn’t use braces around selectors or semi-colons at the end of rules, but feature-wise is identical to SCSS (Sassy CSS), which still uses both of those. 

SCSS is the most common language choice, mainly because it doesn’t differ syntactically from plain CSS, which makes it really easy to adopt the basic principles. Additionally, every major task runner has a module to use with Sass.

There is also a C/C++ port of the Sass precompiler called LibSass that decouples Sass from Ruby. It’s fast, portable and easy to build, and integrates with a variety of platforms and language.

Pros

• Lowest barrier to entry – you can harness some of the most powerful features by simply learning a couple of new symbols
• New collaborators should have no trouble picking it up.
• LibSass (which decouples Sass from Ruby) is fast, portable and easy to build
• By far the most engaged community, with plenty of support and resources

Cons

• As with any framework, there’s a danger you’ll become reliant on this approach, and not fully grasp the underlying language

02. Less

Less is stylistically very similar to Sass in its feature set, and so anyone that has used one will feel right at home with the other. Its popularity got a big boost after it was used in the source Twitter Bootstrap. It has since moved to Sass in Bootstrap 5, but it has left a lot of people comfortable using its syntax. 

The fact it is so similar to Sass makes it difficult to advocate when Sass is more widely used, actively developed, and feature-rich – indeed this feature would be comparing the two (as many have before) if there were more differences and unique selling points about Less. It still remains a popular and strong preprocessor though.

Pros 

• Written in JavaScript, which makes setup easy
• GUI apps can watch and compile code for you (Crunch, SimpLESS, WinLess, Koala, CodeKit, LiveReload or Prepros)
• Very detailed documentation and a very active community
• Easy to find help or previous examples 
• IDEs such as VS Code, Visual Studio and WebStorm support Less either natively or through plugins

Cons

• Uses @ to declare variables, but in CSS, @ already has meaning (it's used to declare @media queries and @keyframes) which can cause confusion
• Time might be better spent learning Sass, due to wider use
• Relies entirely on mixins rather than allowing you to use functions that can return a value, which can result in slightly restricted use cases

03. Stylus

Stylus was created by TJ Holowaychuk – a former programmer for Node.js and the creator of the Luna language. Its initial design was influenced by Sass and Less but it offers a wider range of features, a super-fast Node.js system under the hood, and gives users the most freedom in how they write their CSS. 

This freedom has a downside though. As Declan de Wet says: “It supplies the developer with no definitive direction…once you’re ingrained in variables, mixins and functions not requiring a prepended dollar sign ($) or ‘at’ symbol (@), you’ll soon start to realise that you can no longer tell the difference between them. This makes for very confusing code”.

Mozilla used Stylus to redesign its developer network, and it offers most of what’s covered in the Sass section, but with a few minor differences in syntax. 

Pros

• Hugely powerful built-in functions 
• Can do much more computing and ‘heavy-lifting’ inside your styles
• Written in Node.js, which is fast and fits neatly with a 2018 JavaScript stack
• ‘Pythonic’ syntax looks a lot cleaner and requires fewer characters

Cons

• Too forgiving, which can lead to confusion
• Doesn’t seem to be in very active development

04. PostCSS

Based on its approach, PostCSS is one of the biggest ‘alternatives’ to Sass, Less and Stylus when it comes to preprocessing: it leverages a modular plugin system that allows the user to customise their feature set and compilation as much as they want. This means that rather than just adopting a library in its entirety, you get to choose what it’s made of. 

Unlike many other preprocessors, PostCSS makes no assumptions about the features or stack you’re using. Instead, you simply add the plugins you would like based on the features you want to use. You can add plugins to give it the exact same features as a library like Sass. This modular approach means you can even use plugins completely by themselves, such as auto-prefixing and minification, rather than building a full library.

Pros

• Un-opinionated, modular approach – can be heavily customised
• Written in pure CSS, so developers don’t need to learn a new syntax
• Speed (if you only use a few plugins)

Cons

• Speed (again) – If mimicking another setup, PostCCS lacks the performance benefit a dedicated, optimised tool will offer
• Generally, more effort to install and maintain than a conventional preprocessor, because you’re relying on different plugins maintained by different people

05. Pleeease

Pleeease takes a slightly different approach to preprocessing in that it tries to tackle some of the more practical issues with CSS rather than focusing purely on its syntax or layout. Its website explains: “A Node.js application that can easily process your CSS. It simplifies the use of preprocessors and combines them with the best of post-processors. It helps create clean stylesheets, support older browsers and offers better maintainability”. 

Pleeease provides fallbacks to common issues with older browsers out of the box, including pixel fallbacks for when you’re using rems as your measurement of choice, and filter fallbacks for IE8 when using opacity. 

It even has a feature to allow you to use the syntax of your favourite preprocessor like Sass or Less within Pleeease’s setup (as well as pure CSS), although this is experimental at this point.

Pros

• Built-in autoprefixer adds vendor prefixes, using data from caniuse.com
• Generates source maps in which you can see the original code
• A tool rather than a syntax library, so you can use it with pure CSS or with another preprocessor
• Clear, practical uses for dealing with older browser quirks

Cons

• Not very well known, which may make finding resources difficult
• The feature that allows for the inclusion of other preprocessors is completely experimental at this stage

06. CSS-Crush

CSS-Crush is a standards-inspired preprocessor designed to enable a modern and uncluttered CSS workflow. It’s written in PHP and features a combination of the standard features you would expect in one of the more popular preprocessors (variables, nesting, mixins) along with some of the more tool-based approaches we’ve covered like Pleeease (vendor prefixing, minification). 

CSS-Crush’s PHP background means it can be used neatly in conjunction with popular PHP content management systems such as WordPress or Drupal. This is probably its biggest pro, because if you’re confined to what you can do inside a CMS, you can install it as a plugin and still benefit from some of the advantages of having a preprocessor. 

One bonus is that its vendor prefixes for properties, functions, @-rules and even full declarations are automatically generated. This means that you can maintain cross-browser support while keeping your source code clean.

Pros

• Neat integration with popular PHP CMSs (WordPress, Drupal etc)
• Open source, so you could theoretically fix your own issues
• Useful plugins available, such as working with aria roles and HTML canvas
• Built-in autoprefixing for cross-browser styles

Cons       

• Despite a wide range of features, lacks popularity beyond the regular PHP programming community
• Lack of maintenance (at time of writing)

07. Garden

This option is completely different to all the others because it pretty much does away with the conventional language of CSS as we know it. Garden is a library for rendering CSS in Clojure and ClojureScript. It uses vectors to represent rules and maps to represent declarations. It is designed for “stylesheet authors who are interested in what’s possible when you trade a preprocessor for a programming language.” 

As far as programming languages go, Clojure is known for its clean architecture and firm heritage. For CSS, this can mean great power. However, the syntax can be daunting. As an example, to set no font-weight on h1 and h2 tags, you would use: user=> (css [:h1 :h2 {:font-weight "none"}]).

Pros

• Access to the core features of a powerful programming language in Clojure
• Unique opportunity to code a project entirely in the same language: Clojure for  backend programming and Garden for CSS
• Garden Gnome plugin enables you to pipe style changes directly to the browser without reloading

Cons

         

• You can't simply copy and paste CSS from elsewhere into your work – every snippet must be converted to the correct format
• Very different syntax to regular CSS or any other preprocessor, making it more difficult to read
• Learning curve for Garden is steeper than other options

08. Styled Components

This last option is a pivot from conventional preprocessors. I only raise it in this context as it’s a way of writing your styles in a certain manner and layout and having it convert, alongside your component logic, as browser-ready CSS. Only the basics are covered here and its style handling. 

Styled Components is ‘CSS-in-JS for the CSS folk’ as Glen Maddern put it. It’s the latest attempt to make truly modular CSS by interweaving it into the JS components you write. It has a big advantage over inline React styling as you don’t have to camel case your attributes, and you declare each style block directly onto the name of the element you’ll be using it on. 

So for example, to create a title component that’ll render a <h1> tag with some styles, you would write this:

Pros

• You can achieve total encapsulation of your components – every piece of markup, logic Large following, and active community and project owner
• Represents a fascinating shift in direction
• Preventing ‘append-only styles’. What are append-only styles?

Cons 

• You are back to writing plain CSS, which has its drawbacks
• Quite opinionated, as it’s built to work solely with the React JS library
• You have to handle cross-browser issues and fallbacks using other methods

This article was originally published in creative web design magazine Web Designer. Buy issue 276 or subscribe.

Read more:

• How to structure media queries in Sass
• 7 things they don’t tell you about the web industry
• How to set up site theming with CSS variables

View the full article