What I Learned from CSS Preprocessors

I love cascading style sheets(CSS). I love how simple it is. The syntax is so straight forward and easy to learn, it was love at first sight. For me, writing CSS is an art. It’s not just about making a website look identical to some Photoshop design. It’s about writing lean code, that’s flexible and has as little redundancy as possible. It’s about writing clean, organized, object oriented CSS that’s well commented and a pleasure to come back to months down the road when updates need to be made.

But lets not kid ourselves, CSS is old. Its first version has been around since 1996 and CSS2 since 1998. It’s been over a decade and a half and we’re just now able to use CSS3 without worring too much about browser support… sort of. But the internet has only become a more complicated place. With the rise of the mobile web, tablets, television based web browsers and retina screens, our work as front-end developers has grown exponentially.

For a lot of us, just writing CSS like we did in the days of fixed width designs is no longer enough. We need more tools at our displosal to be able to develop a pixel-agnostic experience. So some really smart people put together what’s known as CSS preprocessors.

What are CSS preprocessors and why you should be using one

I’ve been using preprocessors—mainly LESS—for the past year. It’s been a great learning experience and every project that I’ve had the opportunity to sharpen my skills on has taught me something new about how to author stylesheets. I—like many others that have dipped their toes with preprocessors—can’t imagine authoring styles without them.

Essentially what preprocessors do is take code written in the preprocessed language and compiles them into basic CSS that we all know and love. But by doing this, we can use awesome things like variables, functions, interpolations, operations, nesting and mixins in our precompiled files. As long as the output is CSS, the features we can have available to our preprocessors are only limited by the language they are written in.

There are actually quite a few preprocessors available but the most popular are LESS, Sass and Stylus. I don’t think there’s a right or wrong answer when choosing one, it’s mainly preference and making sure that the preprocessor has all the features you want to use. I personally went with LESS, mainly because it is written in JavaScript and JavaScript just so happens to be a sexy language I also love. But again, there’s no right or wrong answer.

So with all that out of the way, here are the things that I’ve learned the past year.

Learn to write good CSS first

This is important. If you don’t already know how to write proper CSS, don’t try and learn to use a preprocessor. Your goal for using a preprocessor should be to output good CSS that you would have otherwise written yourself. And if you don’t know how that looks, then you’re not going to get much value out of them.

Work locally

It’s how we work on the web these days. Gone are the days of working on a live site through FTP. Start using version control software like Git and build your projects locally. I can tell you about horror stories where files get lost while moving them to the server, someone uploaded an old version of a file which replaced someone elses work or losing connection in the middle of an FTP save and files getting dumped. For brevity's sake, it’s just a lot safer to use version control on projects and work on a local copy.

This is even more important when you start using preprocessors because now there’s a compiling stage to worry about. There are some different ways to compile your styles either through command line or applications like CodeKit. But no matter the route you go, working locally will be faster, safer and makes you better suited to work on a team where multiple people may be working on the same project/files.

Write Object Oriented CSS

There are a lot of great resources about writing OOCSS that cover the “what”, “how” and “why”’s so I won’t go over all of that. But this is a way of thinking about CSS that I’ve incorporated into my own workflow. It’s especially powerful when working on a project that potentially has hundreds of screens and states.

This is also where preprocessors really shine. Primarily because of the “mixin” feature. Mixins let you group styles and potentially set parameters that you can reuse throughout your code. This lets you reduce redundancy, give you a centralised place to update similar style groups and makes your code way more flexible.

Organize your styles in separate files

This is something I’ve started to do even before writing LESS files. If you’ve ever used a `reset.css` file, it’s pretty much the same idea. The benefites of writing your styles in this way is that you compartmentalize styles. So you can put together a `typography.less` file that handles all of the common typography styles you would write regardless of the project. Then you can just edit that file specifically depending on the current project needs.

The more you do this, the quicker each next project you work on becomes. You can easily remove categories of styles you don’t need, or plugin ones you do. So if I’m not using modals on a project, all I have to do is not include my `modal.less` file and all that extra bloat is gone! The final compiled stylesheet should only contain the styles you’re actually going to use. Carrying this principle throught your projects will keep your code lean and fast.

Comment all the things

CSS becomes a couple layers more complicated and abstract when you start using preprocessors. If you haven’t been commenting your styles before, you need to start doing it now. It won’t be as obvious what every mixin, parameter or variable does so make sure it’s well documented. Remember, when you compile your code, you should be stripping all those comments out so you aren’t adding any extra weight to your production styles. But you’re going to kiss yourself three months from now when you re-open that well commented`mixins.less`.

Learn from the best

The place I’ve learned the most about CSS is from the pros. Either from books they’ve published or just looking at their source code and figuring out how and why they wrote their code a certain way. You should be doing the same with how you write in your preprocessor of choice.

There are a lot of amazing frameworks that the frontend development community have put together. Check them out! Read their source. Look how they organize their files, how they abstract their code, their naming conventions. Learn from what they are doing.

A lot of what I’ve learned both in how I author my documents and CSS tricks I’ve picked up from studying other peoples code like Twitter’s Bootstrap, Zurb’s Foundation or 960 Grid System. You don’t have to reinvent the wheel. Most of these projects are open source and you can use or tweak their code for your own projects. Do it!

Write your own framework

It doesn’t have to be as comprehensive as Bootstrap or Foundation. But start a mixins file and put code you reuse all the time in there. Put together a grid system. Put together a media queries file with queries you use all the time. If using a popular framework makes more sense for your project, do it! But the underlying idea is to not constantly reinvent the wheel.

If you’ve written styles for a horizontal navigation and gone through the steps of browser testing it to make sure it works in all major browers. Then you’ve written responsive styles for it to make sure it looks good on tablets and phones. Grab that code and throw it into a `horizontal-menu.less` file. Take out the code that’s specific to a projects brand and turn those values into variables. Now you have a file you can continue to improve on.

This is also a concept I’ve played with before preprocessors and usually resulted in my searching for code in `styles.css` files of past projects to not have to re-write menu dropdowns. But now with preprocessors, that code becomes more portable and easier to customize.

Conclusion

The past few years for frontend developers have been crazy. It feels like our workload has more than tripled and the days of fixed width designs are over. Our work is being viewed on a huge range of devices, screens, desktop and television browsers with a new level of user interaction. There has never been a time in history when we’ve been able to reach so many people in so many different ways.

The future of the web is exciting and the work that people are putting out is stunning. Preprocessors help us to make the redundancies of our job less painful and let us focus on making the things on the web we’re truly passionate about.