There’s a fair amount of confusion surrounding CSS preprocessors like Sass and LESS, and I think some of it has to do with the fact that there are so many different ways you can use them. I thought I’d outline the different approaches, and some of the pros/cons to them.
Local compilation: The idea here is that you write Sass/LESS code on your local Mac or PC, run a compiler that coverts it into standard CSS, and then treat that CSS file as if you’d written it directly — upload it to your server, put it in your version control repo, whatever. The compilation step can be done manually, or automatically. For example, Sass will watch your files in the background and compile them automatically as they change. Also, apps like CodeKit and Less.app put a pretty graphical front-end on the compilation process, if you prefer. The advantage to this approach is simplicity, especially for non-programmers. It also doesn’t impact your development workflow much and server configuration at all. The big disadvantage is that other team members never see your Sass/LESS code, only the resulting CSS, which means as soon as they make an edit, your Sass/LESS code is out of date, with no easy way for you to update it.
Compile-and-cache on request: With this method, the compilation of Sass/LESS code happens on the server side, when a new or changed file is detected. This is the method I, personally, am using. I store Sass/LESS code in my version control repository and on my server, and on the first request to a page, that code is compiled into standard CSS. The standard CSS is stored in a cache directory, and is used on subsequent requests. The advantage, here, is that developers need not ever see or concern themselves with the standard CSS — only the Sass/LESS code. Compilation happens automatically and you just don’t have to worry about it. All developers on a team can easily work on the same Sass/LESS files and store their changes in version control. The disadvantage is that it does slow does the first request to your site after a Sass/LESS file has been changed. It’s only the first request, though, that is slowed down, so it doesn’t bother me. Another disadvantage is that this method takes some setup on the server side to get it all working.
Compile on deployment: Another option is to compile Sass/LESS code into CSS as part of the deployment process. Most modern web projects are deployed automatically with scripts (using tools like Capistrano and Fabric), so it’s no big deal to simply add one more line that compiles your Sass/LESS code as the code changes is being deployed. The compilation can happen server-side or client-side, although I’d say it makes a bit more sense server-side, as that ensures all developers on the team are compiling against the same version of Sass/LESS. The advantages are much the same as the compile-and-cache on request method: the developer doesn’t ever have to worry about standard CSS files, and it’s easy for multiple developers to work on the project. They simply focus on their Sass/LESS code, and when the project is deployed, the compilation happens automatically. I’m not aware of any real disadvantages to this method, other than the fact that it takes a little bit of setup to get it working.
There may be other approaches, as well. The flexibility of these tools is a strength of them, but it can also introduce a great deal of confusion. I’ve seen several articles and blog posts coming out against CSS preprocessors for disadvantages that only exist in one of these approaches (such as difficulties working with Sass/LESS files in teams). In an effort to make these tools appear as simple as possible, the Sass and LESS teams have put a lot of weight on the local compilation method in their tutorials, screencasts, etc. Because of this, many folks don’t realize the other methods exist, and that they alleviate many concerns they may have with CSS preprocessors.
What do you think? Are you using one of these methods? Do you have another method to share? Which do you think makes most sense in your workflow?