Musings on Preprocessing

I've been using Sass for pretty much everything I do recently. Here's some musings on the journey. From hold-ups, to trip-ups, to turn-offs. From apps and teams to workflows and syntax.

You Gotta Work Locally

The biggest contributor to me getting on the bandwagon was giving up my going-commando live FTP editing ways. Yeah, Coda is awesome, but it's bad habit forming. It makes it way too easy to work live instead of local1.

Working local is full of obvious advantages. Namely, 1) It's fast 2) You can edit stuff to your heart's content without worry you're screwing up a live site and 3) It allows you to effectively work on a team through version control (more on that later).

So just do it. If you work only on static sites, you can just start doing it. Work from a folder somewhere on your machine. If you work on PHP sites (e.g. WordPress, Joomla, PHP, Vanilla, CodeIgnitor, CakePHP, and a million more) then using MAMP (my screencast) is ideal. Of course there are variants of MAMP for all platforms.

If you are using something like Ruby or Python, well, chances are you know how to set up that stuff anyway so you're fine.

Now that I'm working primarily on projects that run on my local machine, using preprocessors is easy. I use a couple fantastic apps that I'll cover later.

Command line blah blah blah

I'm a designer! I don't know how to use the command line nor should I need to.

That's a very common thing to hear regarding SASS. Here's the thing: I'm right there with you. I hate the command line. You don't need to. I don't, nearly ever, for anything2.

Other turnoffs

As childish as this may seem, another reason it took me so long to get on the preprocessor bandwagon was the crowd. And I'm not alone here.

Man, usually you even breathe about preprocessors and CSS and the LESS/SASS folks dogpile you at greyhound speed.

For a long time I thought: I write CSS everyday. I know CSS pretty well. My workflow is fine. I'm productive. Why does anything need to change?

The real answer is that nothing needs to change if you don't want it to. If you're perfectly happy doing what you are doing: godspeed.

I can tell you that after making the jump, I am actually more productive. And I write better CSS. And the projects I work on are in better, more maintainable shape because of it. And in some cases, faster3. My advice is: don't let people get on your case. Just do what you gotta do. If you get some time to try it out, do it. And do it on a real project. Just tinkering around doesn't count. You gotta really try it to see how it might work with your day to day.

The Apps

I only have experience with Mac apps. Sorry. I'm sure there are pretty good ones for other platforms.

The app that got me started on all this preprocessor goodness was LiveReload (screencast). I'm still a fan. It now available on the App Store for $9.99. It is a menu bar app where clicking the icon in the menu bar opens a window of options.

LiveReload: the menu bar icon, the app window, and a browser with the browser extension installed.

After it's preprocessed, it reloads the page in whatever browser(s) you have the browser extensions installed in. If what you changed was just CSS, it injects the styles into the page without a page refresh. This is particularly useful where you are styling something on a page in a particular state. Let's say a click triggers open a dialog box and you're trying to style that dialog box. With LiveReload, you can leave that dialog box open and the newly injected styles will affect it, meaning not a lot of wasted time clicking and re-clicking.

But I've recently switched to CodeKit. CodeKit's UI is nicer, has more features (e.g. image optimization, JS concatenation) and less weird limitations (you choose whether or not file are preproccessed and where they go, unlike LiveReload where once you import it you can never get it to compile). The only thing I miss is LiveReload's ability to inject CSS without reloading the page, a handy feature for sites with complex states that require multiple steps to get the page back into that state after a reload.Update April 2012: CodeKit is now doing live injection of CSS.

There are a couple of things I don't like about LiveReload though. One is the screen where you tell it the output paths for the complied source:

I hate this screen

Notice the grayed out ones? It's trying to be smart and notice that you've included that file elsewhere. Thus it won't compile. But what if you want to compile it for some other reason? Too bad, no way to do it. It's just not a great UI and it can be a bit tricky to get started using.

It's very easy to change the file paths to where files compile to. And I've never had to teach it, it seems to pick up on the directory structure and get it right from the get go. It will gray out files that are included too, but you can easily turn that on and off.

CodeKit is limited to LESS, Sass, Stylus, CoffeeScript, and HAML. I've found this to be a little limiting, as I've used Jade to preprocess HTML on a few projects. Jade is capable of HTML includes, which can be tremendously useful.

The error reporting on CodeKit is very nice. It's clear what's going on and it feels good when you resolve it.

Contrast that to LiveReload in which a little window slides down from the upper right of your screen with badly clipped text and no close button, and simply slides away once you've resolved it.

CodeKit also is unable to do the style injection that LiveReload can. This is how the creator feels about that:

@chriscoyier I'm up in the air about it. There's something comfortable about SEEING a refresh happen.

Ultimately I think CodeKit is my favorite right now. What sets it above is all the additional features. It can automatically bless CSS. It can concatenate and minify JavaScript. It can tell you what files import any other particular file. And perhaps my favorite: it can one-click optimize images.

Teams

Another possible hold up to getting on preprocessors: working on a team. Specifically a team where multiple people are in and out of the same CSS files you are. If that's the case, all those people need to be set up with whatever preprocessing app you are using (you could use different ones, that's fine. Best if they are all running same core versions of the preprocessor). You can't have some people editing the .css files and other folks editing the .scss files. Those changes to the .css files are just going to get overwritten the next time someone compiles and commits. Preprocessors are unforgiving that way. They don't say "hey looks like there is some different stuff in this .css file from when I last complied it, want to take a look first?" Nope, they just write over it.

It's doable though. In a short period of time, we moved all of Wufoo to SASS. Actually, we moved a bunch of it to LESS, then some of it to Stylus, then all of it to SASS. Oof da. Credit there to Kevin. We also have all new development on SurveyMonkey using a big set of design patterns that are all using SASS.

If anyone has any team strategies for preprocessors, that would be valuable to share!

Compass

There are folks out there I'm sure that are upset at me for not using Compass. I know, I know. I should be. But obviously I'm slow on this stuff. I like understanding things as deeply as I can before proceeding and Compass is still a little fancy pants for me. If anyone has no idea what Compass is, it's a big 'ol set of add-ons for SASS. It means, essentially, that you don't have to write stuff that you'd likely have to write the same way project after project. CSS3 mixins, grid helpers, sprite helpers, file path helpers, and tons more.

My problem is that I'm not ready to relinquish all that stuff yet. I want to write my own. I'm sure the day will come when I give that up, but it hasn't come yet.

Little things that have tripped me up

This article started out with that title before ballooning into all this. But what the hey, I figure I'll still include these little tidbits that caused me a few moments of grief while learning.

Since I write my own CSS3 mixins, I might have a mixin for box-shadow like this:

But that doesn't work. All those commas in there will confuse SASS. It will think you're trying to pass multiple parameters to a mixin that is only set up to accept one. You can't just put quotes around the value you are trying to pass either, that doesn't work. The answer is to use the double-parens technique:

@include box-shadow(( whatever, you, want, just, one, param ));

Another thing that screwed me up was trying to use variables within values, where the variable was only a part of the value. At it's most basic, variable are super easy:

And one last little thing that might be confusing. The & character has special meaning while doing nesting. It equals the selector up until that point. For instance:

a {
color: red;
&:hover {
color: pink;
}
}

turns to:

a {
color: red;
}
a:hover {
color: pink;
}

You've probably seen example like this before. It doesn't quite sell it to do simple examples like this, but believe it or not, nesting feels natural very quickly and you'll love it.

But back to that & character.

You don't need to do this:

.module {
& h3 {
}
& p {
}
}

That's just implied because of the nesting, you don't need to use the & there. You only need it when it's not going to be a descendant selector (space). Things can get extra sexy when you use the & later in the selector. Like if you use Modernizr to detect for multiple backgrounds:

body {
.multiplebgs & {
}
.no-multiplebgs & {
}
}

That gives you a really clean fork in how you want to handle the situation of support and non-support, all while keeping the code logically nested within the body { } statement.

That Dang FTP Workflow

Even if I've convinced to you work locally, get on version control, and use preprocessors, there is still that lingering issue of deployment. Your workflow might actually take a step backwards in efficiency if you came from live editing to now working locally, and when you want to go live you gotta manually upload changed files to the server. I'm afraid I don't have a great answer for you.

Nettuts covered it with "The Perfect Workflow," but that relies on a GitHub post-commit hook hitting a PHP file that `git pull`s which doesn't work on any server I have access to and is rare for a shared host to even allow that as I understand it.

This is where app-based cloud hosting really shines. Apps like Heroku for Ruby or PHPFog for PHP work into your Git-based version control workflow flawlessly. You can have it so you have one command for pushing to the repository and another for deploying live, or have it so when you push to the repository it automatically goes live.

Those cloud hosts don't work for everyone though. Back when I did agency work, the vast majority on it was just sites on some generic shared hosting. You could always install Git on those servers, then after you push stuff up to your repository, SSH into the server and git pull from there. That's better but still kinda janky and requires command line usage.

Ideally, apps like Git Tower could manage your Git Repos and also handle FTP, uploading files on command that it knows are out of date.

For those stuck on FTP4 workflows who aren't afraid of command line stuff, this looks promising.

The Other CSS Preprocessors

As I've made clear, I've chosen SASS for now as my CSS preprocessor of choice. But what about LESS and Stylus?

LESS was the first one I tried and honestly I still like it. I quite like how all the classes you write are automatically re-useable as mixins. Like:

That's darn useful and more succinct than SASS would be. But I've been told that mixing classes and the concept of mixins together is fundamentally flawed. I'm not sure how, but there you have it. If someone wants to explain that I'd be anxious to hear.

One major turnoff I had with LESS was when I was getting errors just by using the standard @keyframe animation syntax. So ultimately I had to break that stuff off into another file, but those files had to be .css so as to not trigger the error, then I also couldn't @import them (literally include contents) because of the file extension. Maybe they've fixed that, not sure.

Stylus is nice too, largely because of it's flexibility. It's not going to bitch at you nearly as much as the others. Things like braces and semicolons are optional, not required one way or the other. While Stylus is nice and powerful and robust, I ultimately think the development behind it isn't strong enough to instill confidence in me. It's largely one dude (TJ Holowaychuk).

SASS ultimately won out because it's the most mature, easiest to find information and help about, seems to have the most active and robust development, and has the least bugs.

Tutorials Around Here and Final Words

Just for the record, I'm not going to start putting SASS in basic CSS tutorials around here. CSS will very likely outlive SASS. And besides, I think understanding CSS is far more important than some specific preprocessor way of doing things. In fact, if a CSS newbie asked me if they should learn SASS as they are learning CSS, I'd probably say no. Learn how CSS works and then later see how preprocessors can help you. That's the opposite of how I feel about JavaScript and jQuery, where I feel learning jQuery first is fine. Weird.

Essentially I think you should know what writing really good CSS is like. What that final CSS file looks like. The very file that the browser reads and processes to style websites. Then use a preprocessor to make that final, fabulous CSS file easier to write and maintain.

Point being: Write your sass/less so that the output is exactly how you would have written your CSS without it.

1Yeah, it has Subversion built in, but it feels a bit tacked on. If you're into Subversion (and that's fine, it's easy) I think you're better off with Versions.

2Except for little things like this or at work where I need to start up local servers running Python and stuff like that. But even then, begrudgingly.

3At Wufoo, we moved from combining and minifying scripts on the fly with PHP to combining and minifying through preprocessors, which alleviated server load and made for even more efficiently compressed CSS.

4Obviously by FTP I mean SFTP.

Related

Comments

I’m fairly new to SASS and LiveReload, but so far my only complaint is that I can’t really get the processed CSS laid out the way that I like it. I’m a little OCD when it comes to tab structure and layout of CSS and the final product isn’t really what I’m looking for.

The file that you author should not be the one you deploy. The production CSS should be concatenated and run through a minifier and quite ugly to look at.
Meanwhile your original .sass or .css files are formatted however you like. Take pride in their layout, but be ruthless in making ugly files that go to production. :)

“Point being: Write your sass/less so that the output is exactly how you would have written your CSS without it.”

CSS preprocessors surely help making css more maintainable. The main reason for that isnt’t the awesomeness of the output they produce, but tools (mixins, variables) they offer. Dealing with a large project and being unable to use LESS/SASS features I’d rather try to achieve similar effect using other techniques (like oocss) which would eventually make the output look different. The point I’m trying to make is that writing your css the way LESS/SASS would, doesn’t make it any better.

1) Throw your website up on Github so that any computer has access to it.
2) Set your websites folder (which is a git repo git init) to point to the same remote repo that you develop with locally.
3) Push changes from your local machine, or anywhere else which has a clone of the repository, up to the remote Github repo.
4) Pull those changes down on your server with git pull.

Please explain some constructive alternatives. I have so many cleints that are on shared (only ftp) servers… I don’t see any other way. Even if they had SFTP they wouldn’t still let me install git. The main thing which keeps me holding back on some projects are as well, easy deployment.

Really great article Chris. Thank you for your point of view. Great to see Paul Irish here as well. Keep reading his work to Chrome Dev tools as well, absolutely quality stuff guys, thanks.

I’ve been using Sass for a while now, after writing CSS for many years and I have to say that I agree with almost every point. I can’t talk about the little app tools since I do like the command line. The most important part is that developers first have to understand CSS and then deeply understand what the pre-processors do and how they do it.

I was going to ask the same thing. I’ve been following the project but haven’t tried it yet.

Their approach really intrigues me. You write native CSS files, which is cool, and the developer really tries to keep his syntax close to official proposals where applicable (i.e. the :any pseudo). I think it’s a great middle ground between pure CSS and LESS/SASS. If you’re learning CSS or bringing on a new team member, the CSS doesn’t look as alien while still providing many of the benefits of a preprocessor.

I also like that it’s PHP based and combines, processes, and caches server-side on the fly.

That said, what’s kept me from jumping in is the 1 or 2 things I’d really like to have in a preprocessor that are missing due to its “purity of syntax” approach. I can live without mixins (although I guess aliases can essentially so the same thing), but I’d really like nested selectors, first and foremost (:any doesn’t quite seem to provide the same advantages).

I keep hearing about SASS and LESS but have managed to avoid them for my clunky BBEdit approach, though I’m slightly curious to give preprocessing a try on a current project.

For one reason, it’s unlikely to be SASS. I find their logo of ‘hot secretary on the phone’, and the tagline, ‘style with attitude’ boringly sexist and off-putting. It’s a small thing, just a logo and tagline, but it was the first thing I saw, but there’s way too much sexism in tech as it is.

On a completely different topic, if you’re on a mac, it’s not much of a stretch to ditch MAMP. OSX already has Apache installed, installing MySQL can be done with a package and Sequel Pro is a fine replacement for phpMyAdmin – even upgrading PHP is not too traumatic, and for those who don’t want command line, VirtualHostX or similar makes setting up multiple domains embarrassingly easy.

lol, have you ever read a tiny, 3 paragraph comment on the internet and instantly realized that you could go your entire life without meeting that person in real life. if you’ll pass up a possibly great product/service/tool because you don’t like the logo, I’m willing to bet that you’re not very fun to be around in real life.

@tommy, you ever read those one paragraph comments which have nothing constructive to add to the conversation, only to bash someone else who actually has an opinion? It’s a waste of precious electrons.

50% of the time I work on remote servers but I can still compile LESS (I know this article is Sass but the theory should the same) while working on those. I’ve setup a volume on my Mac using Macfuse/Macfusion, but you can also do it using the latest version of Transmit. It’s like working with the site locally on your machine, except it’s remote.

So I have a remote drive mounted on my Mac with the folders being watched, as if, locally; so any changes are caught and processed.

Regarding command line: I use the command line all the time for various things, but I still dislike using it for “compiling” CSS/JS. You generally need to use ugly, hard to remember syntax, when instead a simple “right-click > [some app]” or integration into my text editor would be better. SimpLESS is pretty good though, I use it for my vanilla CSS.

Our front-end developers just type “make static” or “make static-auto” in a terminal (it’s not scary, I promise) to compile all CSS and JavaScript. The auto option starts a watcher that compiles as soon as a file has been changed.

You don’t need to (and probably shouldn’t) keep your CSS files in your repository, you just run the command to compile and minify the code either before or after you put in on the server. It could be as easy as a “make static-minified” command.

I made the switch to SASS some days ago, and I’m really impressed – I like it. As I am somewhat a workflow perfectionist and catious when introducing new layers of complexity, I investigated possible workflow bummers and some other things the weeks and months before.

Especially what to consider when using features like @include and @extend regarding a certain expected output after the compile step.

e.g. @extend made me aware of the problem you already mentioned. As long as you are woking locally only everything is easy. If you’ re working in a (frontend) team, not necessarily on the same .scss files but on different modules etc. but only one development-server, you’ll get a problem.

Every time one developer uploads his compiled .css the changes of the other guys get overwritten. Version Control won’t help in that matter.

In order to get the best of both worlds, a) the independency of single .css files per module while working in a team – and b) the better maintainability (e.g. variables, used as constants for colours, fonts etc.) and all the other stuff offered by SASS, we decided the only comfortable and most promissing solution would be to have ruby + a watchfolder setup not only locally but also on the development-server.

Instead of uploading compiled .css files, we just upload our .scss files and the compile happens serverside now. So every developer can see his changes and dosesn’t interfere with changes / updates of the others.

Maybe that workflow is obvious for most, but maybe it helps some of you.

That’s very similar to our workflow. We use SASS/Compass with Git, and we have all .css files ignored by Git, so that only the .scss files are held in source control (after all, when you switch to SASS, the .scss files become your critical source files).

This gets around the issue of conflicts when committing .css files in a SASS project, a problem that gets particularly nasty if you have debug output turned on in your SASS config.

And Chris, your whole thing about getting tripped up with your box-shadow mixin and it’s lack of flexibility for multiple shadows… that’s what Compass is there for. Make the jump! As with SASS, there’s no need to use any more of it than you’re comfortable with.

Then you can just call the mixin with one or four parameters and it will pick the appropriate one. Might be a solution for your .dropshadow problem, though you still need to provide .mixins for all the different options you want to use.

I’ve been using SASS in a production environment for about 4 months and I’ve found it to be an incredible timesaver. It’s also pushed me to learn more about OOCSS and SMACSS and makes me want to write all around better CSS. Mixins are indispensable.

Nearly all of the “Little things that have tripped you up” have been solved by Compass. I highly recommend you dig through the docs and start plugging away. Chris’s solutions to many of the css3 Mixins, browser fixes (inline-block, floats) are clever and useful and I find myself relying on them. Give it a shot!

The team-workflow problem has been an issue for me moving forward with SASS. I like what is can do though.

Generally I don’t favor preprocessors, especially haml & coffeeScript because they hide the language so much. But SASS does feel a little different since you’re only extending the functionality in CSS.

I’m always weary about “stuff that produces the stuff you want” (code generation) because in the past, they’ve always come to be bad things and you’re at the mercy of a script to write your code for you. Seems almost Dreamweaver-esk in a way.

Hi there!
Well, I agree that using preprocessors *can* be a big timesaver, as well as mixins and the like have their moments, BUT their far from being production ready on a large scale.

First, as soon as they have emerged, the scene has already become fragmented:
SASS, LESS, Stylus, COMPASS, WTF?!, just to name the most prominent…
(CSS has become successful because it is one standard everybody agreed upon.)

And here is how they all will fail in a production environment:
In every project, there will always come the moment where some hotfix has to be done, and to be done *now*, and the responsible developer will not be reachable, so somebody else will hack a little code directly into the css because that is the file he saw when inspecting the code…
unless there is full documentation about how to submit your fixes (and the person knows about this docu in time).

When there will be a regular touchup these hotfixes might be overwritten by the compiled SASS files etc etc.

Well, which leads me to the point of using preprocessors in teams.
Everyone involved has to be committed upon using that particular technology and has to know how to use it to its full extent. Have you ever tried to do that in a distributed team? No? Ok, have fun.

In distributed teams the situation described above is far more likely to happen, as I can tell.

For myself I cope with the situation by using zen coding [http://code.google.com/p/zen-coding/] and by still submitting normal CSS files.

This whole argument is based on false assumptions. Sass and LESS are not just “production ready on a large scale”, they are “already in production on a large scale”. Look at the list of sites/companies using Sass with Compass on the Compass home page for a small sample http://compass-style.org/ There’s also a little service called Twitter that uses LESS

Have you considered/played with WebPutty.net at all? It’s by no means perfect, but I think it hits a lot of your favorite features of these other tools (and possibly some others not mentioned)…

– it’s browser-based (IE8+, Chrome, FF)
– includes hosting if you want it (backed by Google Cloud Storage)
– you get a live-preview pane that does style injection as you change your stylesheet (just like LiveReload)
– provides a syntax highlighting editor with auto-complete
– SASS support (with Compass if you care to use it)
– automatic minification of your generated CSS (and ability to export pretty-printed CSS as well)
– one-click deployment
– easy to use in your local development environment

It’s biggest shortcoming when compared to these other tools is probably version control. Right now, WebPutty only handles a preview version that you can mess around and try new ideas in, and the published version that is actively being served to your website(s). The good news is that there are plans to add more robust versioning and version control integration in the future.

Great article. For anyone trying to decide whether the overhead of a CSS preprocessor is worth it, I would just add the possibly obvious point that the benefits are directly proportional to the complexity of the CSS you’re writing. If you’re using a lot of CSS3 and working on large sites or multi-site architectures with multiple layers of inheritance, the advantages of a preprocessor are quickly realized.

If you’re a one-person shop working with simpler site structures, your “This is unnecessary” instinct may be right. But of course being curious and learning about new technologies is always a good idea, so you should experiment with this stuff anyway. :)

I hate maintaining parallel versions of local and live sites. I always start out local for the speed advantages, but once the client needs to see something, I upload it to the server where the site stays live– I don’t touch the local copy after that.

I used .LESS on every project (and have for about 6 months) and will continue to do so. (Although your article has piqued my interest in SASS). I started out using the .LESS pre-processing app for Mac which was very convenient while working locally but ruined my workflow when going live: having to edit a local .LESS file, then upload the outputted local .CSS file every time to make changes to a live site is absurd.

What saved my workflow is LessPHP (see http://leafo.net/lessphp/ and https://github.com/leafo/lessphp). It is still in development, but the only real errors I’ve found have to do with processing calculated percentages which is not so hard to work around. Just adding a couple lines in my header.php file automatically checks for a new version of the .LESS file and, if so, outputs the CSS file when the page loads. No need for pre’processing apps or editing or uploading CSS files.

I’m not sure if there are any significant speed/performance concerns with using a PHP based pre-processor but would be interested to know if anyone knows anything about this.

Definitely with leafo integrated into some php framework is a huge gain of time! Last optimisation is the use of dresscss or bearcss to build the lessed skeleton from a html file. It implies that you build your markup first then use the tool. One way among others…

We do our development locally (with the help of GitHub). We use Capistrano to pull from GitHub to the development machine, and then use Capistrano again to deploy to the live server. We’ve rigged it to share common files (icons, images) across all development installations.

I’ve been using a custom PHP preprocessor, but with community support for SASS etc. growing, it sounds like that’s my next avenue of process improvement!

I’ve used Coda for years and tried to comprehend SASS, but the Ruby gem thing and command line stuff threw me off. Bryan Jones’ Less.app turned out to be a perfect fit. Now I’m using his latest, CodeKit–and am extremely pleased. And I agree with you, Chris–the image optimization is sweet.

Another point worth noting is that some powerful rapid prototyping frameworks utilized preprocessing: Twitter Bootstrap (LESS), Foundation has a LESS fork on GitHub, and Perkins (LESS).

Moving to LESS+LiveReload has been fantastic for me. It would feel backwards to not use them now. For those just thinking about wading into the waters, just do it. SASS has a bit of overhead associated, but you can get LESS up and running in a minute.

For those wondering if/why they should use LESS: Have you ever re-written the same hex colour in a file? That’s reason enough right there.

I enjoy the ability to use variables and mixins, and I do see the value of using systems like these in your workflow. However, you must be careful with how you let them impact your coding style, I’ve seen too many great designers begin nesting everything because they can, and you wind up with unnecessarily long selectors, extreme difficulty in overriding styles due to specificity issues, etc.

It’s also less than enjoyable trying to convince your entire team to install the necessary sass syntax highlighting plugins for their favorite editors, and trying to make the developer tools of each browser properly identify the source css as the sass file, and not the generated css file.

If you can begin a project in a way that avoids many of these complications, it’s a great way to use sass/less, etc.

I’ve been setting up my own personal framework using SASS and Coda snippets, but now I’ll be checking out some of these tools as well.

I noticed that CodeKit has an area to display installed frameworks and was wondering if you knew whether creating custom frameworks was possible as well?

Also, one-or-many mixins in SASS can be constructed based on the looseness of SASS lists. SASS lists can be either comma separated, or space separated, and you can have lists of lists so long as the separators are different.

For deployment, I’ve been trying out Beanstalk (http://beanstalkapp.com/). It provides private Git (and subversion) repositories, and has a mechanism for pushing changes to the repository to a server. I have just the basic free account, so the deployment mechanism is somewhat limited, but I believe for the paid accounts you can deploy both to a staging server (automatically when the repository is updated) and then manually to a live server. It’s pretty sweet, and is easy to use (if you understand GIT, of course).

I second that, Dave. Beanstalk is by far the best way to go, in my experience, when you’re an agency and every client’s hosting setup is a bit different.

It has the enormous benefit of standardizing the deployment process, so your whole team deploys through one point. And it can show you a report of everything involved in that deployment, such as what files changed, what tickets were closed, and what git/svn commits took place.

@cipa It doesn’t look like Bitbucket has deployment — in other words it does provide free PRIVATE Git repositories (cool!), but they don’t have a mechanism to push those files to a web server for staging or live deployment. That’s what intrigues me about Beanstalk.

I’m at the stage where I develop WordPress themes locally and host them on a git repository ( just the theme, not the whole site), as a backup.
you can get free private repositories at assembla.com. For public projects I prefer Github, but for client sites I use private repos at Assembla.

Coolness. I didn’t know about MAMP (so that’s what I found useful about this post). I love working locally – one of the sites I work on uses a rails server (and I code in HAML and CSS… not SASS yet, sorry). But I also work on a lot of WordPress sites, and haven’t even bothered to look at the local options.

I prefer the .sass syntax, too. No curly braces and semicolons everywhere = less typing, more readable, more fun IMO. Then again, I’m an old Pythonista ;)

Many people are not comfortable with the whole indentation-based thingy, though, or feel it strays too far from what plain CSS looks like. The good news is, both syntaxes are interchangeable, i.e. you can import .sass into .scss (and vice-versa) and it’ll compile without conflict. SASS even comes with a command line tool to convert source files between the two flavours, should your tastes change.

If you want to reload CSS into a live page without the other tool, it’s pretty easy to do so in javascript. I have the following in my javascript and call it as needed (you could put it on a timer or I’ve seen a bookmarklet to do it too). This uses Ext to find the DOM nodes and I force a different URL so my webserver can cache the file but this bypasses it, and it’s using underscore.js to iterate the loop but it’s pretty simple stuff

And yeah, make gives you an easy way to script “recompile everything that’s changed and put it somewhere” – personally I transfer files to my dev server by simply having the dev server mount my working folder so I can test without having to commit changes to source code control etc, and I use emacs so it’s pretty simple to get emacs to always recompile SASS files whenever you save them… but that’s what happens when you get old skool C++ developers working on your web projects :)

“The purpose of Bourbon Sass Mixins is to provide a comprehensive library of sass mixins that are designed to be as vanilla as possible, meaning they should not deter from the original CSS syntax. The mixins contain vendor specific prefixes for all CSS3 properties for support amongst modern browsers. The prefixes also ensure graceful degradation for older browsers that support only CSS3 prefixed properties. Bourbon uses SCSS syntax.”

Gonna be honest though, not really digging the command-line hate. It’s really not scary and IMO, Designers & Front End Devs shouldn’t be discouraged from using it. A lot of what we do as Front End Devs on a daily basis is way more complicated.

I guess I don’t understand how someone can cope with JS, CoffeeScript + jQuery, box model, version control and browser quirks, but then hate using the command line. At the end of the day it’s just typing the right things in to a text box to accomplish what you’re trying to do.

I’m still learning a lot of what the command line has to offer, but everything I’ve learned so far as served to make my life easier on a daily basis. GUIs make a lot of things easier, but in their “simplification” they can sometimes obscure or omit some really cool command-line features (See: GitHub App).

It kinda just kills me seeing so many really smart people disregard or write off the command line as lame/frustrating/complicated when it’s obvious they just haven’t been shown some cool things it can do or haven’t taken the time to sit down and learn.

I can speak to that as a former designer turned developer who is just getting into command line. For me it boiled down to the worry that command line is a direct tap into my computer, and unlike the operating system and its friendly UI, command line operations aren’t safe from me—the worst part of the computing cycle. The sentiments I hear from fellow designers are similar, “I don’t want to accidentally destroy my computer.”

I think it’s getting better and you nailed it on the head. Designers and front-end devs just have to be shown that it’s all gonna be okay.

Great article, I’m a big fan! Thought I would share my two cents on how we use pre-processors as a team at Art.sy:

We have a main Ruby on Rails project where we use Sass, Haml, and Coffeescript. We started the project pre 3.1’s asset pipeline so we use asetgems to compile these files on page reload.

To avoid the issues you mention about the confusion of other members wanting to write to the compiled assets we take the dictatorship position and write to our .gitignore file to ignore all javascripts/css files except those inside “vendor” folders. So even if someone wants to write to the compiled assets it won’t be put in version control.

This is all very Ruby & Rails specific, but we also have some projects built on node.js and for that I wrote a little module.

This has worked out wonderfully for us so far, and overall has made our team much more productive.

I find the extra boilerplate work of setting up a system to seamlessly compile pre-processors worth it, especially for big projects. We spend a lot of time experimenting with different UIs and writing a lot of js/html/css so it makes life a lot more pleasant to have robust feature-rich tools like these.

There have been and still are times when have decided work purely in FTP. For a quick turn around project (day or so) this wouldn’t justify a new entry into a vhost file and being persnickety looking at anything other than domain.com/project as the url would be annoying.

Less has completely rocked my World, for Windows users (WinLess) is a nice little prog. It’s pretty much a nuts and bolts compiler, point it at a directory to watch if you have less and css sub-dirs and it would pull and push into those just nicely. Gives you notifications (Growl like?) if there are syntax errors with line numbers. That’s about it really.

Using the right tools has tons of benefits, looking at CSS with a “pre-processing” slant does way more than cascade down a page. That’s for sure.

Still need to get the hang of Git, i struggle to remember the day of the week let alone more syntax. *cryface*

Regarding the (S)FTP-Git-Deployment-Problem: I used dandelion (https://github.com/scttnlsn/dandelion) for some smaller projects and it works like a charm. And after creating a simple config file it only requires one line of command line use: dandelion deploy – that’s something every designer can handle ;-)

@extend is able to function more like your Less example as of Sass 3.2 (gem install sass --pre) with placeholder selectors.
I’ve already converted all of my reusable classes over to a _placeholders.scss stylesheet.

I have automatic deployment setup on the staging environment, so when I commit a group of changes they are automatically FTP’d to stage.?????.com. When we have everything working on staging I typically login to Beanstalk and hit the deploy button to push everything over to live (even if it’s a series of multiple commit’s).

I also have the option to commit to a specific environment by adding “[deploy:environment]” to the end of a commit message. I use this all the time to quickly make a change on the Live site with [deploy:Live].

The client has an account in Beanstalk, and is automatically notified of new deployments. I’ve found that this works well for clients that are typically more technical.

The only downsides I’ve found is that an SVN remove and delete command will not remove the files via FTP. With a more advanced branching setup this can be done, Beanstalk will remove files and directories from your server that no longer exist in the deployed branch.

As a disclaimer, I have no affiliation or connection with Beanstalk. This info is solely based on my experiences working with it.

Hey Chris, thanks for the writeup. I’ve been toying with the idea of using a preprocessor for CSS, but was (and still am) hesitant for many of the same reasons you mentioned. I’m very interested in the perks to using them (most notable – less typing)

It’s good to see that you’ve found yourself more productive using SASS that not using it. I think that is the most important testament. Thanks also for talking about the workflow, that is the main reason for my hesitation. It’s a matter of choosing to use it and also making it the SOP for the team.

Also, on the ftp note. I usually locally edit files and then upload via ftp to a live beta server where I preview my changes. I do this because I work anywhere and so do not want to be bound to one workstation. All the while using version control.

I’m mostly interested if there is something like phpless or lessjs, that will live server side and then compile the css on upload. Then I don’t have to futz with saving files and then finding the updated one to upload to server. This would remove the css file from my workflow completely, I’d only be concerned with the actual source files. Any hints on where to go (coming from soneone not familiar with node or command line)?

Just tried LESS for the first time and ran into a few roadblocks with Chrome. Compiling errors would come and go, but the main drag was that Chrome’s web inspector stopped showing the file name and line number of css styles. Has anyone else run into this? Any solutions? or just try again?

I’m here from the team at Beanstalk – I just wanted to say thank you to all of the loyal fans for mentioning us here. It really makes our team happy to know that people are finding us to be a better way to get their changes deployed. Just a few weeks ago we released a brand new version of our deployments engine and it’s even more badass than it was before. Team deployment notifications & automatic release notes are among my personal favorites.

I’m not sure you do have to work locally. My workflow consists of LESS + lessphp, which dynamically recompiles, minifies and gzips my LESS files whenever I call the stylesheet (which is at url.com/style.php as opposed to url.com/style.css). There is a little overhead with this processing, but when combined with caching the outputted CSS (if there are no changes to the LESS files) this is minimal.

I really love th idea of using LESS / SASS however I use Beanstalk to store mymain repo while devloping if I compile through codekit and then push to the server my team wont be able to get the LESS/ SCSS files they will see the compiled code, is there a way to compile on deploy to the main servers using Beanstalk.

I’ve only just started using SASS and my first impressions are pretty darn good, I love using mixins and @if’s are pretty cool, I am a one man band and don’t have a real need for a workflow that allows for multiple users to make changes to files however, because of reading this I can see the benefits and will start looking into setting up a proper workflow. As always amazing resource Chris thanks.

Just wanted to share my work strategy in light of this post. I use Codekit to process my SASS code while working on files locally located on my Dropbox. After CSS has been preprocessed which takes about a second, I use Transmit FTP to synchronize my theme (wordpress files) online.

Working locally may be faster but I suppose it would depend on what you are working on. I prefer to always have accessibility on my files online and dropbox allows me to have a single location accessible on any computer. This allows me to use both PC for convenience and MAC for pre-processing my code.

Hi guys, my preprocessors journey started with LESS. Very soon I continued with SASS. Everything was really cool but once I decided to write my own framework I spotted several problems. There was no a syntax in SASS which allows me to do what I wanted. I had some problems with the interpolation and at the end I decided to write my own CSS preprocessor. It’s called AbsurdJS http://krasimir.github.io/absurd/. I’m really interested to get some feedback. Here is something like “get started” article.

If you use FTP, write PHP, and need a solution that doesn’t require syncing local files and live files, I highly recommend SCSSPHP. A couple extra files in your project folder and you’re serving compiled Sass. I understand that git deployment is where it’s at, and I do that for personal projects. I can’t change everyone at my company’s workflow; I can, however, slide in an option that allows us to write cleaner CSS without forcing people to learn a whole bunch of new things at once.

This comment thread is closed. If you have important information to share, please contact us.