Lingering Misconceptions on CSS Preprocessors

Published
January 21, 2013
by
Chris Coyier

I recently received this email from a reader who is just getting started as as front end developer and wanted to get into CSS preprocessing. It has a few common misconceptions in it that I hear quite often. So, blog post.

I'm still not keen on LESS. The fact that it requires adding more JavaScript to my pages puts me off. Sass seems a lot more user friendly. After reading your article I'm even more convinced. The only issue I have is the installation. To install Sass I needed to install Ruby, and to install Ruby I needed to install git, and to install git I needed to install the oskeychain helper... Gor someone who is very new to using the command line, this was an awful way to get something so useful installed.

Let's start with this one:

I'm still not keen on LESS. The fact that it requires adding more JavaScript to my pages puts me off.

LESS is written in JavaScript. It does allow you to <link> up .less files and load the LESS compiler in a <script> and it will process them "on the fly." But you should never use it that way, except in really specific testing situations. You should use LESS to preprocess CSS and <link> up the .css files it creates.

The "pre" part of preprocessing you can think of as "before you send these files to the live website."

When the speed of LESS vs. Sass is considered, it's just in how fast they can preprocess the files and turn them into CSS. It's just an authoring convenience to have it have it fast. It doesn't affect your live site.

And then this one:

To install Sass I needed to install Ruby, and to install Ruby I needed to install git, and to install git I needed to install the oskeychain helper...

Oi! That stuff can make my head spin too. Fortunately you don't have to go through all that. Download CodeKit, have it watch your project folder, done. If you're a Windows user, try the LiveReload alpha. I'm not saying you should avoid the command line, but I am saying an app for preprocessing makes things way easier and better.

I can’t agree more with Brad: getting started with Sass through the command line is really not that hard. I thought it would be, but it’s not.

I’m running both Mac and Windows environment, so I didn’t even take the time to try CodeKit since I knew it wasn’t an option for me on Windows.

On Windows, you only need to download and install the Ruby Installer (http://rubyinstaller.org/downloads/), which give you some kind of advanced terminal able to run Ruby (sorry if I’m popularising).
On Mac, you don’t even need to install anything since the Terminal is already able to run Ruby.

Once you get there, it’s not harder. The 2 following commands install both Sass and Compass, nothing else.
* gem install sass
* gem install compass

Then, you have to initialize your project. You have to find a folder. My advice is to manually create a folder where you want, then reach it from the command line.
There are 3 commands to know here:
* “dir” (Windows) / “ls” (Mac) to look for folders; basically it shows you every folders (and files) there are where you stand in your path
* “cd folderName” to open a folder
* “cd ..” to close a folder

Once you’ve find your folder, the only thing left to do is to initialize your project. The second line makes Compass watching for changes in your .scss files to compile them into .css as soon as there is a change.
* compass init
* compass watch

I can’t recommend Scout enough if you are on Windows. It makes the whole process cake. Also their team is helpful.

On Windows 8 Scout wouldn’t work so I reached out to them on Twitter and they got back to me quickly and pointed out that Java had to be installed first.

I have actually meant to make a quick writeup of getting started with Scout because the interface, while it is simple, does not off guidance so your first project setup can be just clicking and hoping to find out what happens.

Brad, I’m using LiveReload on a Windows 7/65bit machine. I use notepad++ for a text editor, and watch the results in a browser. I haven’t gotten into Sass yet so thanks for links above. From the Scout video, it looks like LiveReload is included, and I could keep using notepad++.

Just wanted to point out that the current beta version of LiveReload works fine on a Windows 7 machine. I use two monitors. One for the text editor, one for a browser to watch what I’m doing. All I have to do is Ctrl+s in the text editor, and the browser displays what I’ve written.

Very simple, very fast, has saved me tons of time and makes coding HTML/CSS/JavaScript much faster. It’s also a setup that is completely language independent. For instance, a contact form that includes PHP/MySQL works fine without changing the workflow.

Sass just seems to add a lot of extra steps to that workflow, but I’ll learn it just because there are lots of jobs out there that include it as a prerequisite. I enjoy coding in native languages, but if Sass really does save me time and adds flexibility I’ll use it. The variables and objects parts of Sass leave me unconvinced since PHP/CSS gives me the same capabilities.

Yep, this is what I have used in all my projects for the past year. It works a treat, and means you can do work live on the server, if that’s your thing (remembering to change back to the static .css file once the site is live, to reduce server load).

Using a LESS or SASS-based framework such as Twitter Bootstrap helps tremendously in understanding the true power of preprocessors. It is a lot easier to see preprocessors working in action verus trying to grok everything right away. https://github.com/twitter/bootstrap

I knew about preprocessors but never really understood them until I started working with Bootstrap and Inuit which use LESS and SASS. After fiddling around with those pre built systems I realized how powerful preprocessors were (As well as code kit :)).

I would recommend setting up Node and NPM and then installing the needed preprocessors via that. There are LiveReload servers and such available as well. For instance you can set up grunt (a build system) to run a LR server and compile the CSS for you. On browser side you need to set up the plugin once but after that’s done it’s just great!

So your answer to someone who doesn’t want to install a lot of software he is not happy with as he doesn’t know what it does is that it is not a problem as all he needs to do is to switch to another editor or install some software that constantly watches and changes a folder on his hard drive?

That reminds me of people bashing Flash as it needs to be installed and write browser-specific HTML5 solutions that require people to install a different browser (in a lot of cases in a beta version).

I really think the original email has some very good points and we are right now relying on a flaky set of tools to give us a more convenient way of developing. Nobody questions the usefulness of preprocessors for the initiated but it is quite an overhead in our development tool stack that needs documenting. This is counterproductive to getting browsers to do these things out of the box for us and standards to add the things developers want. John Alsopp really brought this to the point in his Full Frontal talk 30:40 onwards.

The web became such a success as it was dead simple to start creating something. The more tools we add the more complex we make it. If those tools are not reliable and keep changing we concentrate on the wrong thing – we should make it easier for people to use the web, not jump through hoops to write the least amount of code. Case in point is JavaScript – we abstracted all the annoyances away into libraries and now we are faced with a new mobile environment and we realise these libraries are an overhead that is too slow for that. Abstraction is in a lot of cases a short term win that hurts us later down the line.

I think it is very important to question our tools and concentrate on improving the platform instead.

Regarding your comments on JavaScript libraries, I don’t believe that example is an apples-to-apples comparison with CSS preprocessing. I do agree that choosing a library like jQuery over a speedier JS solution potentially forces a slower, less enjoyable experience on your end users. The users have no say in the matter, and indeed we should consider where those decisions are leading us. Point taken.

However, CSS preprocessors (if used correctly as Chris describes above) have no negative effect on the end user whatsoever. In fact, the minification features present in preprocessors like SASS/LESS should actually improve the end user’s experience.

In regards to making web design less accessible, I view CSS preprocessing as one of the many optional tools for use by web designers looking to make their job easier. Creating a simple website straight out of 1995 is just as easy (if not easier) today as it was back then. The barrier to entry on the web is not bigger; the breadth of possibilities is simply larger. The community has acknowledged that reality and started developing their own tools to address new challenges.

You wouldn’t discourage a young web developer from switching from Notepad to a more advanced text editor just because it requires installing a new application. So why discourage CSS preprocessing just because there’s a small setup process, which apps like CodeKit mitigate?

Sure, native support for SASS-like features in every major browser would be great. But do you really think the browser developers would consider incorporating those features if several thousands of web developers weren’t already proving their use case on a daily basis?

I have yet to see using preprocessors as adding efficiency to my process. I have inherited over-nested SASS and LESS files causing output selector confusion. I have also inherited projects with broken workflows using these tools that can be tricky to repair or require re-architecting in order to make a minor change causing project overruns. To add insult to injury, I find setup and mapping troubleshooting tend to use up all of the time I save with mixins and variables. The biggest reason being that in CSS, I just use find and replace in my editor and the task generally only takes a couple of seconds anyway.

Now that it’s 1+ year later, I wonder, are you still coding CSS3 or have you switched to a preprocessor? Has anyone done a cost-benefit analysis of using preprocessors? When you look at the examples on their sites they are (expectedly) rigged in their favor. I want to believe that developers have a level head about this and aren’t just going with “gut feeling” or not questioning the marketing on the preprocessor’s site, but it seems like the industry has accepted preprocessors without di riguer.

On the Apple side, you don’t have to install Ruby, it’s already installed. It’s not up to date, but for Sass and Compass, it’s fine. “Gem install sass”, “gem install compass”, depending on your setup, maybe toss in a sudo.

But for anyone just getting started on front-end development, I would make sure that they understand a few things. One is that CSS preprocessors are the future. Personally I prefer Sass (not Scss) over Less, but that’s because I don’t like the extra markup. The other thing they should understand is that a front-end developer has to be learning ALL THE TIME (which is what makes sites like this invaluable). If you don’t love learning new things, I’d recommend another industry.

As far as installing Git, any front-end developer worth their salt should be learning that as well. Homebrew can make that a one command install.

Personally, I prefer Compass and LiveReload over Codekit. Codekit is fine too, I bought the license, but if you take your front-end development even further and start using tools like MiddlemanApp, you’ll find that LiveReload is already supported.

Excellent post. I really enjoy working with Preprocessors myself. Clarification was needed and very well put. I use LiveReload through the Mac App store simply because that is what I bought. I wish I had known about CodeKit though.

Three reasons why I prefer LESS over SASS:
1. LESS is independent of the server. If I develop a WebApp, I want it to be possible to serve it from any server, regardless of the back-end env. In addition, I often don’t even have access to the server – just to the static directory – so I can’t install and configure SASS. Most of my apps are developed against an API (I don’t have any control on server code).

When testing, I don’t want to compile my CSS files after each change I make, and using LESS enables that – I just insert it as a postprocessor into the index.html, and my .less files are served and compiled in runtime. Lag is usually up to one second – not that annoying.
When I want to create a build for my app, I can use LESS from within the Node.js script I have for “compiling” projects, and so for stable releases, I have only 1 minified CSS file, avoiding the lessjs processing time.

I don’t know about SASS (I believe it can do some pretty programmatical stuff with loops etc) but LESS doesn’t have to be treated like another language per se — it’s more of an improved CSS syntax than a whole new language. Stuff like nested rules and variables make perfect sense to even a novice CSS developer (or should!) and the improvement in productivity and speed are huge (at least, they were for me).

As someone mentioned Fire.app here, I want to include Compass.app which is basically Fire.app but without all the HAML/ERB stuff.

It is just for SASS and Compass and I really like it. Not free but 10$ is a reasonable price I think. The app is cross-platform as well so you can use it on OS X, Linux and Windows. Still not as great as CodeKit but for non-Mac users a nice alternative.

I use LESS, and auto-compile with the handy-dandy SimpLESS tool. You just point your LESS file to your CSS file and it will auto-compile every time you save afterwards. If you happen to have incorrect syntax, it won’t compile, but will show a subtle alert on your screen telling you what line the error is on. Version 1.4 was released back in July ’12 with a (sometimes) broken installer, but until they get 1.5 out you can just launch via the .exe!

My basic tools for making front-end are: Sublime text 2, Scout app and CSS Reloader for Firefox.
I use Scout app on Windows to get the minimized css file. Which is used in the production. Not a big thing to setup for the projects, but the scss save time, and mixins are awesome. I can make sprites on my own in an easy, fast way :)

sometimes I love being in the windows/asp.net/visual studio world. For less, all you need to is install a nuget package, add a couple of lines of code to a bundle, and .net will bundle/minify/cache your less on the fly and serve them to the end user as one big .css file. And in debug mode, it will just convert single files to .css without the combining/minification (so you can easily find what file the style is coming from).

Of course, it first requires you to install python and then node.js with npm. But putting these commands in a tutorial makes installation easy for someone who is new to the command line.

Compiling can then be as easy as typing lessc in the command line.

I think all the new features that preprocessors add to make development easier make them a no-brainer. They’re especially easy for the uninitiated, since you can use it as just CSS without the preprocessor features anyway. You can ease yourself into using LESS/SASS features, and as you ease yourself into them, you’ll find each feature makes something you were already doing more convenient.

It really doesn’t add too much complexity. Unless you want to build from source every time, there’s documentation and tutorials to make this stuff very accessible to the absolute beginner. You just need to learn a little bit more with regards to setup, or you might not even have to do that and just refer to the documentation if you ever need to re-install the preprocessor tools. We can improve on CSS right now, with full browser compatibility, for very little additional effort.

The mixin example given by LESS is exactly the reason you shouldn’t use it…. they are assigning styles to specific id’s and only using them once…terrible!

I have seen LESS files with THOUSANDS of lines of css because people use it badly.

css is designed to be object oriented, resuable and namespaced. If you find yourself writing lots of css with many duplicates then you aren’t doing it properly. please research OOCSS and namespacing and learn your craft properly, rather than using a shortcut which create more junk than Dreamweaver!

I always despair a little when I read things like this. Any self-respecting web designer/developer should take the time to learn basic command line administration techniques. It really isn’t as hard as you think it is and you’ll become a much more efficient user of your computer for it.

Caveat: I do most of my development using Debian GNU/Linux & derivatives thereof, so my setup is probably a little different from that of all you Mac users, but the fact is that Mac OS X and GNU/Linux are both part of the Unix family of operating systems.

I don’t think it’s that simple though. The beauty of css , html and javascript is that they are interpreted rather than compiled. Compiled or preprocessed languages are inevitably more complex ( with lockins to specific dev tools, linkers , naming conventions , platforms … ). So by transforming css into a compiled language, it becomes more powerful but substantially more complex — i think this is at the heart of the concern about preprocessors. This concern isn’t by saying its ok if you develop on a mac and use codekit, in my opinion.

I am using Compass.App for my Sass development. It works on Mac, Linux and Windows :-) http://compass.handlino.com/ I has many of the same features of CodeKit for the Mac, but works on all platforms. It’s only $10

First i used LESS, because it seemed more actively developed than SASS. Then i found Compass, which only works with SASS. I never wrote a single line of “regular” CSS since then. Using Compass and SASS is absolutely a must these days. It just simply saves you a ton of work when it comes to responsiveness, or cross-browser issues, CSS3 transformations, etc.

Thanks everyone, this post has helped me get up and running on the whole preprocessor thing. Im on Windows and What worked for me was:
Liveloader extension for firefox
and scout at http://mhs.github.com/scout-app/

sorry I couldn’t figure out how to make it linkable, the markup didnt work for me

anyway, thanks everyone for the sharing. Now I need a good tutorial on how to code scss so I can learn mixins and such.

I agree with Chris. Somehow we are creating tools, which actually going to make our life miserable sometime sooner or later. Any Frontend Engineer first of all need to understand the basic technologies, which browsers and platforms understand. I won’t prefer some JavaScript library to generate CSS file, might be that build up interdependency on different parts of basic Web tools.

This problem would be more severe when we want to have unified web application for desktop and tablets. One side best practices for mobile development is suggesting to avoid the JS libraries and coming up with as tiny as possible JS libs. If we want to add one JS which would give you better CSS, then its not suggested.

Everything which is helpful for you, could be complex for others, but always should be independent. It doesn’t matter how many packages and dependencies needs used code, if it possible to move and re-use code. You can, but shouldn’t use prepocessors if don’t know how work selectors, priority or inheritance. Start with basics, then learn advanced technics.

I put off learning the whole css preprocessor thing for far too long. I’ve installed on both my Mac and Windows 7 based PC. Sure the PC install took a little bit more work to get Ruby up and running but once you actually start using SASS and maybe drop in some other cool little bits and pieces like Compass or Susy, you sit back and wonder what you’ve been piffling around at hand coding every line of CSS for over the years.

To broaden the discussion: What’s the sense of CSS preprocessors built with Ruby (SASS) or Node.js (LESS) if your webapp doesn’t use Rails or Node.js? If you webapp is written in .NET or .PHP why wouldn’t you just use those languages to generate a CSS file? You could use whatever variables, loops,… you need in .NET or PHP syntax that you’re already familiar with.

If you are using only basic features, I think Bart is correct that you could just as well write your CSS as a PHP or ASP template. But make sure that you only run this script once each time you modify your template, then link the generated CSS file on your pages! Serving up dynamically generated CSS files will either conflict with or bypass browser caching mechanisms for CSS files, and potentially waste CPU cycles on your server. Aside from this condition, the only real advantage I see to using a preprocessor (if restricted to basic features) is that the preprocessor’s syntax will look cleaner than a templated CSS.

Of course, it’s possible to accomplish the same thing using pure CSS, but it will be more difficult to read and write, especially if you have more nesting levels and longer class names. To implement the above using a PHP template would require parsing the template, and converting it into pure CSS. By the time you have done that, you are well on your way to implementing your own preprocessor, but one that lacks the numerous advanced features offered by existing preprocessors.

This comment thread is closed. If you have important information to share, you can always contact me.

Treehouse is where you go to learn HTML, CSS, and how to build iOS apps. It's a complete education in modern web and app technology, designed to get you ready for a hot new job or to kickstart your own business.

The Lodge is a member login only area with access to video training on how to build websites from scratch using the best modern tools.

How many people touch the CSS in your current main project?

What now? I have some ideas for you.

Go explore CodePen!

As a front end designer and developer, you should have an account on CodePen so you can save your snippets, present your ideas, and engage with the rest other front end folk. I'd encourage you to go PRO as well, to unlock the full power of CodePen.

Get the newsletter!

You should sign up for the CSS-Tricks newsletter. It's a clean copy of all the blog posts each week, combined together, right to your inbox. If email isn't your thing, there is an RSS feed, iTunes, and lots of other ways to subscribe.

Listen to ShopTalk!

Subscribe to The Lodge!

The Lodge is a members-only, ad-free video learning area here on CSS-Tricks. Just like the free screencasts, but organized into four large complete series. Membership is also the #1 best way to support CSS-Tricks.

We can do the real footer now.

Site Links

Colophon

CSS-Tricks* is created, written by, and maintained by Chris Coyier. It is built on WordPress, hosted by MediaTemple, and the assets are served by MaxCDN. The fonts are Source Sans and Source Code Pro. It is made possible by viewers like you who subscribe to The Lodge and through advertising for products and services I like.