CSS was both a wonderful innovation and a missed opportunity. Being able to separate the form and the content of a webpage massively improves the process of web design. But, CSS has a number of limitations. As anyone who has ever written CSS knows, for all but the most simple of sites, the CSS can become a tangled mess of repetitions, overrides of previous CSS, and overrides of overrides. CSS does not conform to coding best practices, and its simplicity steps over the line from simple to simplistic, frequently hindering the design and development process.
Thankfully, CSS preprocessors provide us many of the features that would ideally have been included in CSS from the beginning. There are a number of different CSS preprocessors, with the most popular being SASS and LESS. There are significant differences between the two, but rather than looking closely at particular preprocessors, we’re going to have a look at how CSS preprocessors in general can change the way you think about writing CSS.
Image by What Is A CSS Preprocessor?
Put simply, CSS preprocessor languages are more feature-rich than CSS alone and can be processed into CSS that works as normal.
As the name suggests, CSS preprocessors take a text file, process it, and output correct CSS. Exactly what that text file contains depends on the individual preprocessor, but both SASS and LESS are a superset of CSS. They include everything already in the CSS specification plus additional features. A major benefit of which is that if you know CSS, you can already write valid LESS and SASS, and just need to learn a few extra tricks.
Variables, Mixins, and Functions
CSS does not include variables. Anyone familiar with coding understands how useful variables can be. Variables allow web developers to assign a value to a name, which can then be used throughout the stylesheet. If you need to change the value, you only have to change it in one place, rather than hunting through all of the CSS files for every instance.
Image by Mixins are slightly more complex. They allow for the properties of a class to be embedded in another class, which can then be used throughout the stylesheet, in much the same way as a variable. Functions are much as you would expect to find in any other programming language, although with some limitations.
It Will Make Your CSS DRY
“Don’t Repeat Yourself” is one of the foundational best practices of modern coding. With CSS alone it’s almost impossible to adhere to, but with SASS, LESS and the others, variables, mixins, and functions allow developers to write their styles in one place, and use them throughout their stylesheets.
CSS Preprocessors Will Save You Time
Image by All of the inefficiencies in the way CSS is written and maintained take up a lot of developer time. Using a CSS preprocessor drastically simplifies the task of writing readable, maintainable CSS, which means developers and designers have more time to work on the really important stuff, like making the site look good.
If you’ve been avoiding CSS preprocessors, perhaps it’s time you gave them a look. They will save you time and they are very easy to learn for anyone already familiar with CSS.
Nice article, those arguments are totally right when you don’t ever know how to make right & maintainable CSS without prepros.
I prefer to use JS libraries like PrefixFree(https://leaverou.github.io/prefixfree/) or Myth(https://www.myth.io) but i miss there nested CSS like in LESS or SASS. Previously i have to use LESS with LESSHat but i didn’t like it because you have to pay attention what CSS rules are prefixed. With PF or Myth you don’t have to…
You can turn prefixes on and off with booleans.
Also newest version includes prefixed and prefix-free version.
I see the DRY argument brought up a lot and it’s totally incorrect. CSS is not a ‘programming language.’ It doesn’t ever ‘run,’ so the final processed CSS file will still be full of repeated styles. Usually more repetition then if you just wrote standard styles that properly utilize the cascade.
I agree 100% with you, Ben. Ultimately your final CSS file will be bloated.
Both wrong, DRY totally still applies, but on the development time scale, not the file size, or interpretation time. The file size will be negligible, but with Sass, it takes you half the time to write it.
Any argument to bloated CSS is also moot. You’re never going to encounter a project where one developer uses a preprocessor, generates a CSS file, and then someone else has to come in and work on that CSS file. They’ll always continue working with the Sass/Less/Stylus file.
Honestly, if you aren’t using a preprocessor, you’re wasting a ton of your own time, and you’re falling behind the times. Suck up the fact that you may need to spent 1 or 2 days getting used to it, and enjoy the fruits of your labour when your CSS dev time is cut in half.
The only pre-processor that I would give a try is Stylus, just because of its bracket-less syntax. Preprocessors for the most part, allow you to mix styles in css, but also produce bloatware. I’m also a big advocate of mixing styles in html (ex ) instead of the in the style sheet, for this reason I have not found big advantage of using pre-processors. I’ve also seen too much bad css output after somebody used pre-processors such as SASS or LESS.
Good css starts with good web-design mockups. If your mockup is too convoluted, then perhaps you do need to rely on pre-processors to get your project done.
I’ll expand on Ben’s comment: Good CSS begins with good design, well-formed HTML and well-planned classes. This article is one of the best I’ve read on the benefits of using a pre-processor. However, I’m still not convinced that it is necessary for a skilled CSS coder who has control over the HTML output.
I agree that variables and functions are very much needed in CSS to keep it DRY. Also prefixing becomes easier.
What I don´t understand is, why would someone want to learn a new language/syntax when you could generate your static css with simple php. I wrote a simple php script to do exactly that. https://github.com/Tehes/PHProCSSor
Tell me what you think of it.
Your argument makes no sense, PHP itself would be a new language to some people. Sass and Less especially have very very few syntactical differences than vanilla CSS. Nesting is a simple concept, so really, it’s just learning how to write mixins which is still easier than writing PHP, to process it.
My solution was adressed to developers that at least know some basic php, which should be quite a few people because many designers/developers know how to handle a CMS as well.
But your right, for people that don`t know php, my argument really makes no sense.
This was a great article to spark some interest for those that haven’t dived into preprocessors yet. I personally prefer SASS, and one of the best things about SASS is being able to use mixin libraries like Compass or Bourbon, which can save a ton of development time – especially if you use styles that require prefixes (which thankfully are quickly becoming a thing of the past).
Another great feature of SASS is being able to import separate SASS files into one master file for final export – this is a great feature especially for developing responsive sites, it keeps your files tidy and organized. Combine all of this with a compiler like Prepos or Codekit and all of your styles will be automagically compressed into one master file for final output – awesome.
@Ben
I think Stylus is another great preprocessor, however it may be a bit daunting at first for those that are looking to get started with preprocessors since it’s based on Python script structure. SASS and LESS are easier to get into since they use the same structure as CSS.
I think this is a great article! I would have liked to see some preprocosser code examples. This link has some awesome code examples for anyone interested to learn more: https://developers.google.com/chrome-developer-tools/docs/css-preprocessors
I use SASS when I’m coding on my localhost, but using it on a live server is so cumbersome, it’s completely not worth the time. What I used to do was use the preprocessor to build the site locally and then straight up CSS to maintain and adjust the live site. That was cumbersome as well, so I just switched back to CSS. I really don’t see a huge difference for skilled, and experienced developers.
if you dont create css correctly in the first place a PP will not help you, non-DRY css can be created both ways, but adding another unnecessary step is the programmers way admitting they can’t create DRY css,… what’s next preHTML,… dealing with an extra step is just programming obnoxiousness 🙂