When it comes to languages that power the web, CSS is a double-edged sword. Often heralded for being quick to learn, like chess it takes awhile to master. Due to its simplicity, it is easy to get to a point where CSS files become unruly, mired by code repetition and lack of consistency.
Enter CSS pre-processors (and post-processors). Of all the CSS pre-processing approaches, Sass (Syntactically Awesome Style Sheets) is the clear front-runner.
Metaphorically, Sass is to CSS what jQuery is to JavaScript. Not only that, Sass gives CSS a seat at the table of first-class programming languages.
CSS on its own is not programmatic, it is declarative. You define what colors, fonts, and dimensions are used in a page and the browser renders it. Simple enough, except for the aforementioned pitfalls of sites that are built a larger scale.
Sass is a superset of CSS that enhances the language by adding:
- Variables
- Math (helpful for responsive layouts)
- Comparison (if/else) logic
- Loops and enumeration
- String interpolation
- Reusable "code injection" mixins
- Inline compilation of
@importpartials - CSS output minification
Since it is a pre-processor (running either locally or on the server), Sass also adds the ability to read from the file system. This allows Sass to "watch" changes to *.scss files and live compile them to *.css as a developer makes edits.
When it comes time to deploy the site, flat CSS files are pushed to the server, and the live environment incurs no additional overhead.
It's a win-win. In this era of modern web development, sites are increasingly being built with pre-processors like Sass.
Beyond pre-processing, there are also helpful tools like PostCSS and Autoprefixer.
https://github.com/postcss/autoprefixer
These can be used to add "-webkit" and "-moz" style vendor prefixes to CSS properties. This is helpful for cases where featuers are still being defined as a specification, and browsers differ slightly on syntax.
While a developer could opt to write a pre-processor mixin that handles vendor prefixes, handling this via a post-processor build step means that developers are freed up to simply write the "standard" syntax only, and allow the build step to insert the requisite vendor prefixes.
As these syntaxes are standardized, one can then simply remove the relevant post-processor rules from the list of build steps, and voila, the next time the CSS is compiled there won't be any unnecessary "legacy" vendor prefixes.
PostCSS can also be used to "lint" (check for code quality) the compiled CSS files. This is helpful to maintain a consistent coding style throughout a development team. For instance, it could be used to check for overly qualified selectors such as div#id or ensure that certain naming conventions are followed, like BEM.
https://github.com/postcss/postcss-bem-linter
Overall, we highly recommend using Sass as a pre-processor, and then using Autoprefixer and/or PostCSS, depending on the needs of the project. We believe these tools offer a great boost in productivity for modern development teams, affording us the ability to move fast and use new features, while also supporting older browsers that are still in use today.
^ I wrote that explanation for a coworker, part of our documentation explaining the modern front-end dev environment and workflow.