Preprocessors and task automization

CSS Preprocessors are used to compile a processed language into pure CSS which can be parsed by a browser. Preprocessors provide extended functionality to css to make code cleaner, more reusable and more scalable. By utilizing things such as variables and mixins, css preprocessors can allow values which would generally be repeated throughout the source such as font styling or a common color in your design.

Preprocessing css during development also means that large css files, which in a complex application would quickly become large and unwieldy, can be broken down into smaller files containing only the css for certain aspects of the application.

So what? If your only concern is styling in css, splitting things up into multiple files may seem unnecessary and messy. However, if you’re working with styling, markup, managing the database and front-end and node javascript it’s much less likely that you’ll be as intimately familiar with the position of certain elements within a large css file. Having multiple files clearly named by view or by page means that you can directly access the styles you’re looking for.

It’s also arguable that you can split css into multiple files without bothering with preprocessors by using @import or simply embedding multiple files in your markup. But loading multiple files on from the side of the user’s browser incurs additional http requests which impact loading time. ‘@import’ing stylesheets from within stylesheets compounds this problem as it requires the first stylesheet to be loaded before even beginning to load additional files.

Using preprocessing for css means that there needs to be software on the server to handle the css before it is distributed to the client. The decision of which preprocessor to use was largely a tossup between SASS and LESS. Ultimately SASS won out as it uses syntax similar to traditional css which i’m more comfortable with whereas LESS uses a whitespace-based syntax. SASS can be installed via npm and utilized by the project server to compile the css at runtime. Doing this would enable the css to be individually tweaked before being sent to the client. However, as this type of functionality isn’t necessary for my needs and will theoretically have a performance overhead, I’m going to use the Grunt task runner to compile the css during development.

Grunt can be configured to monitor files for changes and execute commands when the files are updated.

During development, I’m also going to use grunt to monitor changes to the server source files and automatically restart the server when the source is modified.