You are able to declare custom functions with Sass (for example, converting units) which can be easily invoked, even when using shorthand properties. This results in cleaner, more reusable code.
Sass allows you to nest selectors which results in code that is both faster to write and cleaner to read.
For example, this:
.parent
color: blue
.child
color: yellow
Will compile to this:
.parent {
color: blue;
}
.parent .child {
color: yellow;
}
Another big advantage for Sass is the very active community pushing the development forward at a rapid pace. Sass is constantly coming out with bug fixes, and are often the first to come out with improvements.
This is an important factor to keep in mind when picking a preprocessor to invest your time into.
It comes with two possible syntaxes:
Sass - No parens or semicolons allowed and the nesting is dictated with whitespace.
SCSS - SCSS syntax is a superset of CSS – which means SCSS can be written as CSS, but has been expanded to include the features of Sass as well.
SCSS is easier to pick up for beginners and Sass has a cleaner syntax. Having both syntaxes means you can pick the one that best suits your coding style.
The mandatory syntax rules for both SCSS and Sass results in a more consistent code. For a more detailed analysis between Sass and SCSS go here. To see a nice comparison of the Sass syntax against CSS and SCSS go here.
Sass can be used with a framework called Compass, which provides additional functions and mixins which can reduce the amount of code you have to write.
For example, Compass will take care of vendor prefixes.
This:
div {
background-image: -webkit-linear-gradient(#F00, #000);
background-image: -moz-linear-gradient(#F00, #000);
background-image: -o-linear-gradient(#F00, #000);
background-image: linear-gradient(#F00, #000);
}
Can be written as:
.gradient {
@include background-image(linear-gradient(#F00, #000));
}
For a full list of features, check out the Compass documentation.
There is also a C/C++ port of the Sass CSS precompiler called Libsass that decouples Sass from Ruby. It is very fast, portable and easy to build and integrate with a variety of platforms and languages.
The latest implementation of Sass is written in Dart, and compiles to pure JS with no native code or external dependencies, means you no longer need Ruby or libSass.
Stylus has an extremely terse syntax. Colons, semicons and braces are all optional allowing you to write Stylus code however you want.
hover-darken(percent)
if @background
&:hover
background: darken(@background, percent)
.test
background: blue
hover-darken(50%)
The hierarchy is required to be whitespace indented which makes it easier to identify which parent selectors child selectors belong to.
Not only does Stylus support all the features from Less and Sass, it provides features not found anywhere else:
You can get properties from parents and pull them into children and/or mixins - if the property isn't found, it will bubble up until it finds a match
Introspective API, where a CSS block can tell if it’s at root level or not and change its output based on this
Splats - taking variable amount of arguments in as an array
Automatically vendor prefixes @keyframes
Pass a CSS literal block wherever you want
Convert files to base64
One of Stylus' distinguishing features is transparent mixins: reusuable, possibly dynamic styles that look exactly like native CSS properties. This is particularly useful for using future non-prefixed properties and having them transparently expand to their prefixed counterparts without any special, preprocessor-specific syntax.
Nib is Stylus's answer to Compass, but with the advantage of transparent mixins.
Ride css add dozens of useful mixins to Stylus. Compatible with axis, nib and other mixins libraries.
Roots is a awesome toolkit that contains a CSS library for Stylus that provides the benefits of Nib and more. It is essentially a collection of mixins that add a variety of enhancements to the Stylus workflow.
Stylus can also convert files to base64 which provides the following advantages:
Easier to maintain
Gives you the cleanliness of a URL link resource as well the benefits of base64 encoding
Reducing the number of requests
Development of stylus has stagnated, there are lots of known bugs and it does not work well newer features like CSS Grid or custom poperties. See https://github.com/stylus/stylus/issues
The Stylus syntax is very loose and that leads to ambiguity where some definitions can mean different things. For example, hashed objects cannot be used when you choose to omit colons in your definitions, because the dot notated object getters could also be a nested class selector. As a result, you lose being able to use hashed object getters if you decided to write Stylus without colons.
Stylus is younger than both Less and Sass, and not yet at the same level of popularity. As a result, Stylus currently has a smaller and less active community than the two more popular options.
Due to having such a loose syntax, the coding style can vary between different Stylus projects, making it hard to apply styles from other projects that use a different syntax style — at least if you care for consistency.
Stylus relies heavily on whitespaces to separate and define code blocks. While this makes for a cleaner syntax, it's also easier to make mistakes when indenting stuff, especially when working with someone else's code where you don't use the same style of indentation.
Because Less has a lightweight feature set, is syntactically similar to CSS and can be run client side with file conversion on a page reload, it is easy to pick up by anyone familiar with CSS & the very basics of JS.
Also, Less has detailed and well-organized documentation, GUI apps that can watch and compile code for you and a huge, active and helpful community.
Less contains the base feature-set for a CSS preprocessor:
Nesting
Variables
Basic mathematical operations
Color functions
@import
Basic type functions
The '@' symbol is used with Less to declare variables. However '@' already has meaning in CSS, as it is used to declare @media queries and @keyframes. This can result in some confusion when reading the code.
Less does not offer custom functions and instead requires the use of mixins. This is limiting in many ways - Functions cannot be called on shorthand values, they cannot return a value, and code needs to be repeated depending on where the mixin is needed.
The immense flexibility of PostCSS plus its current rapid evolution makes it harder to install, configure and keep running than the more monolithic and mature preprocessors.
PostCSS allows you to opt-in to the features you need with plugins. This allows you to set it up to behave exactly like Sass, with nesting, mixing, extends, and more. On the other hand, it allows you to use plugins by themselves for things like auto-prefixing, minification, and more. You can even set up your own custom "stack" of plugins to do exactly what you like.
Some plugins can only work if initialized after some other plugins. For example, transforming and applying CSS variables needs to run before running a plugin which uses these variables inside conditional transformations.
Currently there is very little support for syntax highlighting when writing PostCSS plugins. But, if you use .css or .scss file extensions, the plugins for CSS or SASS syntax highlighting should work just fine.
Because the parser/compiler can function in a web browser, it can be used with systems that cannot run similar technology on the server. For example, you could build a WordPress plugin with a front-end application that transforms CSS.
Through transforms you can modify existing properties to give them new attributes and options, so instead of managing messy mixins, you can add a simple new attribute where they make the most sense.
Because Rework plugins are done in code, there are no limits to what they can do, and they tend to provide more advanced functionality that would be harder to implement in other preprocessors, such as file I/O and custom logic.
Rework isn't a language for compiling to CSS but rather a library around parsing it and transforming it. For example, a vendor prefix plugin will inject prefixes around needed properties so you don't have to muddy up your CSS dealing with it.
Because Rework is built around plugins at its core, it makes for easier plugin writing if you find you want to add in new functionality.
Rework has a more involved setup that can make it an intimidating first option for beginners to css processing. As Rework is built around plugins, the documentation can't be found in one spot. The quality of documentation also varies between plugins.
Although you don't have to, since Rework works on vanilla CSS, you could use another preprocessor that has a syntax you enjoy more before applying Rework's transforms.
Rework plugins can recognize custom properties and transform them via plugins. This allows you to keep your CSS clean and expand its functionality in a native feeling way, without having to learn a bunch of new language constructs.
It's written in node, so you can install it with npm. All available plugins are installed by default and include some development tools like a watcher and a browser live-reload so it don't need more than few seconds to be ready to start to work.
The parser detects any CSS syntax error found. The output code can be customized to follow your own code style rules (indentation, spaces, string quotes, etc). It has a clean and powerfull API, which make easy to create new plugins.
Since Stylecow is pretty small and hasn't gained a lot of traction in the past 5 or so years since it was first released but also because it serves kind of the same purpose as PostCSS which is much more popular, there have been discussions on merging the two projects together.
Sly has just 5 stars on Github and a very small adoption rate. For an open source project this usually means less bugs reported, lesser documentation and few third-party learning resources.
With Garden, you have access to all the core features of a powerful programming language to build your scripts, including functions, variables, namespaces, and data manipulation like map merging or concatenation.
Garden finishes the full Clojure stack experience — you can have the entire codebase in a single language with ClojureScript on the front-end, Clojure on the backend, and Garden for CSS.
Using the core Garden auto loader or the excellent Garden Gnome plugin, watch your style changes take effect in the browser as soon as you save the code — no reload required.
Clojure is a data-oriented programming language with strong emphasis on simple, clear inline data structures. Garden models styles using these same structures, making the cascade visually obvious.
Other options listed include various pain-points like use of @ symbols or too much cruft; because Garden is just Clojure, and Clojure is a very well-designed language aimed to emphasize simplicity and positive developer experience (without semantic whitespace problems), you have the full benefit of a well-designed and general-purpose syntax.
preprocess CSS (experimental)
adds prefixes, based on Autoprefixer
provides fallbacks for rem unit, CSS3 pseudo-elements notation
adds opacity filter for IE8
converts CSS shorthand filters to SVG equivalent
packs same media-query in one @media rule
inlines @import styles
minifies the result
generates sourcemaps from pre- to postprocessors
Pleeease uses Autoprefixer to add vendor prefixes based on which browsers you want to support (prefixes are added based on information from caniuse.com.
The keywords are shortened to 3 letters. For example, "background-color" becomes "bac" and "max-width" becomes "maw". These keywords are far less intuitive than their original form and make the CSS much less readable for those who don't know CSS-On-Diet.
CSS-On-Diet has just 7 stars on Github and a very small adoption rate. For an open source project this usually means less bugs reported, lesser documentation and few third-party learning resources.
The author, Dan Cederholm, explains the basics of Sass - mixins, variables, common functionality - in an easy to understand way and with clear examples.
It's not uncommon for designers to be skeptical of Sass at first. The author himself was reluctant convert. "Sass for Web Designers" does an amazing job of explaining the "why" behind Sass and how it can make the life of a designer much easier.