Plastikwrap

For the last few years ‘frameworks’ (or ‘boilerplates’, or ‘bootstraps’) have been all the rage – they’re intended to provide developers/designers with prefabricated foundations for their work, removing some of the tedium involved in some of the more robotic aspects of web design and development. I admit that I came a little late to that party – it was only in September 2010 that I stumbled across the 960 Grid System and the full benefits of a CSS framework became clear to me. Prior to that I hand-coded pretty much every site, and many a yard of my hair was lost trying to figure out the idiosyncrasies of the various browsers (not naming any names, but this was of course at a time when version 6 of a certain browser was still very prevalent and still required full or near-full support). It was pretty revelatory to me to have a massive chunk of that work done already.

So by no means am I disparaging the idea of frameworks – when done right they can be a great example of open source in action and can be genuinely useful. I’m always cheered by the work that people put into these things to prevent others from having to re-invent the wheel – the altruism/kudos incentive is a fascinating thing. I have a lot to thank them for, as do my clients, in saved time and cost and, of course, enhanced end results.

Lameworks (ho ho)

But there are downsides. Given the number of frameworks out there it’s quite easy to be overwhelmed and to worry that you’re using X when you should be using Y, or that if you only used Z your life would be Just Awesome™. My approach has been to proceed with caution – don’t assume you need something just because it’s new and shiny. Even when I have come across something that looks genuinely useful, my experience is that it takes time to overhaul my workflow to integrating new tools and practices, and attempting to do too much at once can be really confusing and ultimately counterproductive if those new tools or code conflict or create new and novel administrative burdens. I personally find it more effective to note down new tools/approaches/ideas as I find them (while reading blogs or web dev sites) and play with them outside first in a sandbox, outside of the real development context, to find out whether there would be real value in integrating them properly into my workflow.

A problem that didn’t need solving

I’ve lost count of how many web ‘apps’ I’ve signed up to which are supposed to enhance my productivity but which I’ve realised, on reflection, don’t actually solve any problem I’m experiencing. Web 2.0 is littered with these answers to problems that don’t exist – and as much as I admire the entrepreneurial zeal of the starry-eyed Zuckerbergs who create them, the vast majority do seem destined to fold sooner or later, and no amount of 1px white text shadow and noisy background textures is likely to change that.

Nagging doubts

Depending on where you rank on the perfectionist scale, frameworks can also have the welcome side-effect of making you constantly feel like there’s unfinished business with your past projects – a nagging desire to retrospectively inject some of the new whizzbang skills you’ve acquired to bring those oldies up to the cutting edge. It’s worth remembering that you were working with what you knew at the time, and if everything was and still is working, and the client was and is happy with it, then you did your job. Most clients have no interest in the gubbins anyway – if it looks like it works and it smells like it works, then (to them) it works.

It might sound like like I have a downer on frameworks but that’s not the case at all, and I’ll describe which ones I use in a later post. My problem isn’t with frameworks per se; I’m just wary that all the choice out there can create more problems than it solves. Bizarrely, the incredibly positive trend in the web community towards share techniques and code to make each others’ lives easier can, if we don’t step back a bit, confuse matters and distract us from concentrating on the core skills necessary to create websites, on both the code and organisational sides.

This entry was posted Saturday, February 11th, 2012 at 11:56 am and is filed under web development, workflow. You can leave a response, or trackback from your own site.