zahnster

When I started at Zenbe, I was pretty excited, because I knew it meant that I would be getting my hands dirty with some complex development issues. My history in web development has been mostly creating smaller, marketing-oriented websites, where you don’t really have to worry about frequent code evolution or long-term maintenance. Once you create the site, it’s up, and maybe there will be text changes here or there, but for the most part the code base (especially things like the css) are left alone.

But what do you do when your product is a complex web application? How do you best maintain your stylesheets when your app is constantly growing and evolving? It’s a lot more challenging than you might think, but there are several things you can do to keep your code optimized and maintainable.

In order to organize my thoughts, and perhaps throw some inspiration on the subject, I’m starting a series of posts each featuring a different thing you can do to best optimize and organize your css to face the challenges of a frequently evolving web application.

The first thing I’m going to talk about is the importance of an asset packager. It may not seem critical, but it really is, as it empowers you to create maintainable css documents.

For those who aren’t familiar, asset packagers allow you to combine different stylesheets into one big, compressed stylesheet. On smaller apps, it’s very common to include the entire site’s css into one file (or a very small number of files). This is good practice – performance rules state that you should minimize http requests. However, with a complex app, forcing all of your styles into one sheet can be a quick road to disaster. Once your css is above a certain number of lines (500+ in my eyes), it can become very verbose, unorganized, and difficult to maintain.

For bigger apps, it’s very helpful to piece apart your style rules into different files based on functionality. For instance, with Zenbe, we have many (many!) different stylesheets – we’ll have one for base styles and one for the different buttons we have. We’re not afraid to break up our css in the smallest chunks possible, because it helps our files have meaning. If there’s a style problem with a button, I know it’s in buttons.css. I don’t have to dig around for it in some obscure, 10,000+ line global stylesheet.

When you make the choice to break apart you css into small, manageable chunks, you’re breaking the optimization rule of minimizing http requests. Even if you use @import, each fetched stylesheet still requires an http request. So, this is bad, right?

Not at all, because this is where asset packages come in.

Originally built for Rails by Scott Becker, the asset packager we use for Zenbe actually compresses all of our different stylesheets into one file. It does this on the server level, so you can easily combine any number of stylesheets while only having one http request on the client level. An added benefit of the asset packager is it also strips all extra spacing, so you can use the ‘1 line per style’ css code style without feeling guilty about whitespace and file size.

Asset packager isn’t just for rails, either. There’s a PHP version out there as well, which was inspired by the one Becker wrote. If you use a different language – check around for one in whatever you program in. It’s definitely worth it.

So that’s basically it for asset packages. I can’t express how important it is to use some form of this on any complex applications – nothing kills app development like trying to keep some global stylesheet organized and maintained on a complex app that’s under constant revision.