Loading
Back to all posts

CSS Preprocessors for Legacy Applications

First choice: which CSS preprocessor, Less or Sass?
We chose Sass.
The Sass server side compiler runs on Ruby which is quick and easy to install on Linux, whereas Less is compiled by node. We decided that installing Ruby was the better option.
Setting up the Sass compiler on our live servers and local virtual boxes was a simple three command set up:

sudo yum install ruby

sudo yum install rubygems

sudo su -c “gem install sass”

After installing Sass, we decided that setting up some basic CSS guidelines would be the first step to tidying up our legacy application. The guidelines themselves could be a whole other article, but it’s important to get these set up before starting down the path or implementing your preprocessor, in order to keep your code consistent from the outset.
Next we decided on a file structure. We currently have all our CSS in a single CSS directory. We decided to create a new subdirectory to store the Sass files to then compile into the original parent directory. The current file setup was not appropriate; as with many legacy systems the files had become messy, with unused and duplicate code and file names with no meaning at all (style.css). We decided to follow a similar approach to the bootstrap css framework, splitting elements into files as cleanly as possible, and then defining individual files for special pages which did not confirm.
Finally we started porting the code across. We found that the easiest way to do this was to simply copy and paste code from the CSS files into the relevant Sass files, ensuring that each file compiled (as Sass can compile vanilla CSS).
Upon completion of porting all the CSS into Sass, we compiled the entire suite into a single CSS file. This took just over 5 minutes due to the large number of files and the amount of CSS accumulated over time in the system. This is obviously not acceptable for local development, so we decided to compile each file individually into its own CSS file, and load them into the system separately. This meant that only the individual file that was changed required compiling each time and so cut the compilation time down to a few seconds. Far more acceptable.
We then edited our deploy/build script so that when we deploy to live, the script compiles all Sass files together into a master CSS file and then the system uses that single file. This does have the adverse affect of slowing down our deploy process, however the resultant improvements make this a worthwhile exercise.
Once the file had been ported over, we refactored the CSS in compliance with our guidelines, moving any commonly used styles into mixins and putting all commonly used colours and sizes into variables, both having their own file. On completion of each file we would then load the front end, running some quick manual tests and acceptance tests to ensure nothing was broken beyond use.
To prove just how much of an improvement we made using Sass, we compared our previously minified master CSS file which was being generated by bundling all our CSS files together using PHP and our new, compiled, CSS file generated from the Sass compiler. Our previous self compiled CSS file comes out at 118KB. Not too bad.
Our new, compiled CSS file comes out at just 94KB. Thats a saving of 21% (24KB).
 
Find out more about Sass and Less in this post from HTMLMag