Let’s talk about frameworks
So you’ve been hearing all this hype about “frameworks”. People from all over the world of web design and development are raving about the way their lives have been changed by things with mysterious names like “Rails” and “Django”, and you’re scratching your head, wondering what all the fuss is about — is this just a fad that’ll pass, or is this a geniunely important new development? Maybe you’re wondering just what, exactly, these “framework” things are, and what they can do for you.
Some of the answers to these questions are pretty simple and some aren’t, but over the course of a few articles here I’m hoping to explore and answer them, hopefully in a way that’ll help you develop a better understanding of the new frameworks and whether one of them is the right choice for your next project.
So what the heck is a framework, anyway?
When we talk about a “framework” in the context of web development, we’re basically talking about a set of tools that’s designed to help you quickly build some sort of web application. Maybe that application is a content-management system for a business. Maybe it’s an online store. Maybe it’s a social application like Flickr or del.icio.us. Whatever the application is, a good framework is designed to ease some of the burden of its development by handling common, tedious or repetitive tasks for you.
A typical framework will provide libraries of code for handling things like data modeling, database access, page templating and URL mapping. It may also go further and attempt to give you components for common situations like user authentication — the general idea is to provide a useful baseline of suitably generic functionality that’s needed by most web applications.
Wait… that’s it?
But, of course, it’s all been done before. Web development frameworks are nothing new. The MVC development paradigm used by so many of them is nothing new. Object-relational mapping (the system used to translate between abstract concepts like “blog entry” and more concrete things like database tables) is nothing new. Templating languages are nothing new. And so on and so forth — everything old is new again, and a lot of people are left wondering what all the fuss is about. If these “new” frameworks are just the same old ideas, why are they suddenly popping up like weeds and getting mentioned with breathless awe?
The big belly
Take a look at the graph to the right. It’s not perfectly accurate, but it’s a rough representation of the continuum of web development in terms of the amount of infrastructure and development needed to sustain sites of varying size.
On the left is the most basic sort of site — a personal home page, maybe with some pictures of a cat. This doesn’t require much, if anything, to set up; the hosting for such a site can be had for free, and there are simple WYSIWYG editors to be had, also for free, which put creating this sort of site on the same level of difficulty as creating a word-processor document.
On the right is an extremely large and complex site or possibly sites — something like, say, Google. In terms both of infrastructure and development, this is a monster.
But look at the middle. The graph curves up sharply from the cat-pictures site, taking into account the needs of more complicated and dynamic sites. And at the other end it curves up sharply again, representing the massive expenditure needed to sustain something on the scale of Google. But in the middle it’s almost flat, and it stays almost flat for a long time. These days it’s fashionable to talk about graphs that have a “long tail”, but this one doesn’t: it has a big belly.
As you ramp up through that initial spike, a number of things have to be added fairly quickly — databases, server-side programming and so on — but once they reach a certain point they stay fairly constant for a while. A significant percentage of situations can be handled by a database-backed server-side application, and the only thing that increases significantly in the belly of the graph is hardware: you can start out with shared hosting, then move to a VPS, then to a dedicated server, then to a few web servers and a dedicated database.
So once you’re in the belly of the graph, the actual code being run doesn’t have to change very much. In fact, it might not have to change at all; dropping a load balancer in front of the application and a replicated database setup behind it is fairly easy to do, and the application doesn’t necessarily need to know about it. In fact, it’s probably better if the application doesn’t know about it; just kep cruising along and adding hardware as you need it.
And the fact that you can just cruise along and add hardware means that, in the big belly, the overall complexity of the system doesn’t grow a whole lot; an application on the right end of the belly won’t be very much more complex, when considered as a whole, than an application on the left end.
For a good framework, this is the sweet spot.
Where no framework has gone before
It’s also a spot that, previously, frameworks didn’t really aim for. Frameworks were Serious Tools for Serious Developers, and they tended to be big and complex and cost a lot of money either to obtain or to deploy, sometimes both. As a result, frameworks tended to be a viable option only for the folks further to the right on the graph. But now things are different. The frameworks that are proliferating now are lighter-weight and open source. Where before frameworks tended to be written in static, verbose languages like Java (in fact, almost all the popular ones were in Java), now they’re appearing in more dynamic and concise languages: Ruby, Python, Perl and PHP. These languages are immensely more popular with good programmers than Java ever has been or ever will be, and they’re orders of magnitude easier to deploy and manage on average hardware. They’re even available on common shared hosting.
Which makes frameworks look a lot more attractive to a lot more people. Some of this does undoubtedly have to do with marketing, but a lot more, I’d say, has to do with open source and language choice: “free” is a price that’s hard to beat, and the experience of just sitting down and writing code instead of sitting down and writing 500K of XML configuration files is a a big draw for a developer, in addition to being a big productivity gain for a team manager.
So framework-driven development is now a lot simpler and a whole lot more accessible than ever before; for certain tasks, it’s now possible to use a framework to build an application while writing less than five hundred lines of code, and have it work on hardware setups ranging from Dreamhost to dedicated clusters. For other more complex tasks, it’s now possible to bring the advantages of frameworks to bear on problems that were previously not quite big enough to justify a monstrous J2EE setup. To steal a motto from the Perl guys, the easy things are easy and the hard things are possible.
And that, I’d bet, is the reason why we’re seeing this sudden proliferation of frameworks and framework-driven applications. But that’s not all there is to say on the topic; over the next week or so, I’ll be going more in depth, looking at the advantages and disadvantages of frameworks from a variety of perspectives. Even though it’s already been touched on by some colleagues of mine, the next installment will be looking at frameworks through a designer’s eye.
Stay tuned.