One of our developers Crunchie (we have too many people named Chris in the office so have to resort to nicknames!) explains all about front-end CSS frameworks.
So what are front-end CSS frameworks?
Front end frameworks provide a way of grouping together similar concepts, practices, and functionality with a view to serving solutions for specific sets of issues that arise time and time again. For example, a carousel here, a sticky nav there! As front-end developers, we're requested to provide these nuggets on a regular basis. Wouldn't it be great to simply call upon a pre-determined set of files to quickly build such elements from a single generic codebase? Front-end frameworks seek to provide developers with the ability to do just that.
CSS frameworks such as Twitter's Bootstrap ship with default grid styling out of the box, with additional functionality available at the flick of switch. Using jQuery we can easily lay our hands on modal windows, carousels, mobile/responsive grids, forms, buttons etc. There's a whole heap of fun stuff to play around with.
What are the benefits?
All browsers, all devices
Thankfully, much of the cross-browser compatibility testing and responsive CSS has been done. Call me lazy if you like, but why re-invent the wheel? Surely it's better to re-use CSS/JS code that's proven to work cross browser and on plenty of mobile devices as a jump off point? Frameworks (with some ‘tweaking’) can be real time savers when it comes to rapid responsive development.
In an agency, enterprise or studio environment, many developers, both front and back-end will be working with the code. Documentation for the aesthetic layer is a valuable asset to have, especially as a production site grows through various designs, layouts and changes. Projects often out-live the developers that built them, so having solid documentation makes handovers a sweeter experience as new developers have a solid framework and documented best practice to work within.
But what are the pitfalls?
Mark-up can be rather span and div heavy, resulting in massively bloated code and CSS. However, familiarity with your framework and a staunch adoption to the 'way' of the framework will stand you in good stead to combat the bloat. You can’t code for a framework as you would if you were coding for a bespoke project - you need to learn the framework to a suitable level before using it for production code.
It's easy to spot framework based layouts
Although we seek some form of presentational uniformity, it has been suggested that a grid / framework based approach can often be too constrictive for designers and developers. We all struggle to think outside of the grid sometimes, so entrenched have we become in our box based layouts, so viewing it all in neat little square boxes can lead to numerous homogeneous designs. This may not be a bad thing as a certain level of standardisation is required in all human / computer interactions. But targeting users in an emotional context, i.e. making them ‘feel’ something often incites great click-through / conversion and interaction. Having said that, we must force ourselves to remember that a framework is just a tool, there's always a way to break out of the grid if you really want to.
Too much stuff
Granted, many frameworks do ship with an awful lot of stuff. It may be stuff you don't need, or stuff you will never use, and if it is, maybe a framework is not what you need! A harsh lesson, best learnt from tales of woe, as opposed to experience. Frameworks will drive you crazy on small builds that don't require them. Instead they are best used for projects that tick all the requirements.
If suitably tailored to the right project and managed with a sound understanding of the subtleties of the particular solution used, frameworks can readily lend themselves to aiding the production of great work. They are by no means an all-round solution; they can be complete overkill on small sites. It is possible to roll your own solution and further reduce the overall burden by minifying the CSS and removing the JS components you don't need. But sometimes, only bespoke will do. The smartest thing you can do with front end CSS frameworks is know when to use them. Figure this out and you will see how useful they can be.
And to back it up…
Talk is cheap, so next time, we will be building out two test sites with one using Foundation4 and another using Twitter’s Bootstrap. Let’s see how they bench, can we break them and more importantly can we improve their overall performance through planning and intelligent use of each framework? Either way, it will be interesting to see real results.