Unless you’ve been living under a rock for the past five years you’ll be aware that frameworks (large collections of modules and libraries that abstract away the more mundane aspects of programming) are what all the cool developers use for creating web applications. You’ll probably also know that the most popular of these frameworks, in the sense that it’s the one that gets talked about the most, is called Ruby On Rails and if you are, like me, somewhat of a web development junky, you’ll probably also have tried out building something small with Ruby On Rails to find out what all the excitement is all about.
Unfortunately, these pre made web programming frameworks tend to be highly complex and difficult to learn. For any but the simplest of use cases you will need to have an intimate and in depth knowledge of how the framework actually works and for obtaining that knowledge it is necessary to have digested vast amounts of documentation (if such documentation exists at all, which isn’t always the case). This will take an investment of time that is hard to justify unless you happen to be one of those rare people that actually makes a living building one web application from scratch after another. From an economic point of view, it may, in fact, make more sense to simply copy over some code from a previous project every time you start a new one. The amount of time you waste doing this pales in comparison to the time it would take you to learn the intricacies of Ruby On Rails, Django or the Catalyst framework you need to know in order to be productive.
Being a developer, however, you detest (and if you don’t, you really should, detest) copying and pasting code from one project into another. Code that is worth copying and pasting is code worth abstracting out into a library, after all. So the thing to do the next time you’re about to begin building a new web application is to spend some time designing components that can be reused easily in case you need to build yet another application from scratch at some point in the future.
In effect, what you’re doing is creating your own framework from scratch. This may seem like a bad idea because, after all, there’s so many well designed (and tested!) frameworks already out there and it would seem wasteful to duplicate those efforts, but it really isn’t: a framework you design yourself will only do what you need, it will do it in a way that makes sense for you (one need only look at the terrible complications Ruby On Rails imposes on you when you’re trying to fetch data from two different tables into one model object to see why that is a bonus) and, best of all, you will become intimate with it with no effort at all while you’re busy implementing it.
Over the course of the next several days, weeks or months (depending on my desire to write) I wil be talking about the steps I myself have taken to construct such a framework for a web application I needed to build. In no way am I going to suggest that those steps are steps that you should take as well. However, reading about how someone else tackled a specific problem may give you some ideas about how you yourself could go about building something that works for you. Stay tuned!
(see also part two and part three of this series)