Over the past year or so I’ve written several articles on frameworks, mostly talking about the pros and cons of using them and specific design decisions pertaining to specific frameworks. For the most part this has been in the context of programming — specifically Python and JavaScript programming — because, well, I’m a programmer; this is what I do for a living. But every so often the general topic of frameworks for the Web, recently focused on frameworks for client-side technologies, rears its ugly head again and people have all the same arguments over again. Which is a shame, because they tend to obscure more relevant (and, hence, more important) arguments.
What follows here is not an opinion on any specific framework or any particular use of a framework; I’d simply like to lay out some definitions and common themes, and hopefully provide some framing for future discussions which will avoid the need to have the same tired flame wars every time this topic comes up.
Way back when I started my original frameworks series, I tried to provide a definition of “framework” which made sense for server-side application frameworks like Django and Rails:
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.
That’s still not a bad definition for this narrow scope, and gives some hints toward a broader definition; the key phrase is this:
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.
And in the slightly broader context of all web development — back-end or front-end — the idea of a set of reusable components to cover common situations works well. I’ve written, for example, about what I think makes a good JavaScript “framework”, and this definition covers my wish list pretty thoroughly; there are some things you have to do all the time in JavaScript, which are tedious to write out by hand every single time, and so a single, reusable implementation that you can call upon whenever you need it can be an awfully handy thing.
Also on the front end, CSS frameworks like Blueprint or the YUI CSS tools follow the same pattern: CSS-based design work tends to involve a fair number of common, repetitive, and ultimately tedious tasks — sidestepping browser default styles, laying out a grid, standardizing typography, etc. — which seem as if they lend themselves nicely to being handled by a reusable framework.
In general, this sort of development pattern — identifying common tasks and abstracting them out into a single, reusable implementation — is one of the most important in a programmer’s repertoire. You’ll sometimes hear people joke that good programmers are “lazy”, and what this means is simply that good programmers tend to see duplicated work as a bug, and try to fix it. The result, in many cases, is a framework.
While I’m on the topic of definitions, I’d like to pause and consider a largely semantic, but seemingly contentious, debate about just when the word “framework” should be used, and whether there’s a difference between “frameworks”, “libraries”, “snippets” and various synonyms of these terms. Personally, I think the difference is largely in how each one is used, particularly the extent to which the finished product is coupled to the “framework”. Some examples will hopefully make this clear:
XMLHttpRequest and implementations of specific DOM features like event listeners can probably switch pretty easily to using a different set of wrappers; parts of the application which fire off XMLHttpRequests or attach event listeners will need to be changed to use the new wrapper functions, but the logic which decides when to use those functions and which handles the responses and events will probably come through unchanged. This is a case where the term “library” is probably most appropriate; switching doesn’t involve a complete rewrite, but is still a bit of work.
Any of these can, in theory, simply be collections of code a single person has built up through experience on various projects, or can be polished into a released product intended for general use; collected snippets of code can become a published “cookbook”, and libraries and frameworks go from private to public all the time.
It’s also relatively common for a set of snippets to become a library, and for a library to become a framework; Blueprint, for example, is quite clearly a framework (because the overall CSS will rely heavily on it, and will likely need to be completely rewritten to switch away from it), but it’s easy to see how it evolved from a library of more isolated components, and how those in turn evolved from collections of snippets.
And it’s possible, though not quite as common, to work in reverse: frameworks sometimes change direction and begin evolving into libraries, for example (Zope has been heading that way for a while).
Now that we’ve got a decent baseline for deciding what a “framework” is, we can delve into some of the common themes of arguments about frameworks; for the most part, they fall into categories that I’ve already covered (twice, actually), but I’d like to revisit the topic and maybe explain it a bit more clearly, because many common criticisms of frameworks — in all fields of web development, from back-end programming to front-end behavior and style — boil down to a single argument: “this is a trade-off I don’t want to make”.
Most commonly, you’ll hear points like the following:
In each of these cases, the argument gets obscured by the use of overzealous generalizations. What’s often being said is not “Framework Y is bad because of X”; rather, what’s being said is “Framework Y is not a good fit for my project because of X”, which is an entirely different thing.
Consider the first argument: frameworks “bloat” your final deliverable with all the extra code that you’re not using, but which has to be included in the framework in order to serve general-purpose needs. In actual practice, this is a trade-off to consider, and “will this bloat my product” is entirely the wrong question to ask. Instead, you should be asking questions like:
mod_deflate) to reduce file sizes before sending anything over the wire (and, in fact, most such frameworks offer “full” and “minimized” versions for precisely this purpose).
In other words, black-and-white pronouncements of “Framework X will bloat the application” are next to useless outside the context of flame wars; the job of a professional is to look beyond those sorts of generalizations and ask, instead, what trade-offs will be involved in using the framework and whether those trade-offs are acceptable for the particular project you’re working on. The same is true of all the other over-generalized arguments:
The fact that most of the broad generalizations used in arguments against frameworks are really better articulated in terms of trade-offs to evaluate in the context of specific projects means that most broad generalizations used in favor of frameworks are of the same substance:
There’s a lot of hype and a lot of bile right now surrounding web frameworks of all sorts, both front-end and back-end. I think this is mostly due to the fact that they’re gaining much broader visibility; while framework-based development has been standard practice in a lot of “enterprise” shops for years now (almost exclusively in Java or .NET-based languages), it’s only with the last two years or so that they’ve really become accessible and attractive to folks working in the “big belly” of the Web: designers and developers working on their own, or at small- to medium-sized shops where the footprint (and, often, the price tag) of the older frameworks ruled out their use. And with a larger audience comes a larger and louder debate.
The lesson to take home, though, is that there are no quick and easy decisions. Deciding whether to use a framework at any level of your development process isn’t something you can base on the heated and essentially overgeneralized arguments made by people on both sides of the debate. Instead, like pretty much everything else in this industry, it comes down to careful evaluation and a series of trade-offs: there (still) ain’t no such thing as a free lunch, but that doesn’t mean you can’t shop around for a reasonably-priced meal.
Tomorrow: back to Django blogging.
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
Best. Blog post. Evar!
Thanks for making sense out of a mess, James.
Welcome back!
Thanks! Since I am not a native English speaker, I never threw myself into the discussion about CSS (and JavaScript) frameworks. But you speak my mind !!! Thanks!
Uh… Did you just write a framework for frameworks? :)
@C.W. Miller IV : I think you can call this one a library* :P
(*the post can be decoupled to refer to any software or design artifact as mentioned in the post)
James, great article in explaining the wide scope of the idea of frameworks and how each are different by their task and obligations which they “enforce” upon the user.
Although I think that CSS is very simple and doesn’t require a “framework” as in the sense of application back-end “framework”, there are always common reusable elements of CSS which are repeated among different projects (typography, grid/columns).
Therefore two month ago I decided to publish those CSS snippets that I commonly use, calling them Konstruktors CSS snippets. Here is my philosophy about them.
As a Django evangelist I honestly have a problem seeing the situation when not to use the framework if you can make that decision. In my first projects using django i didnt know django (i didnt even know python) but the development time was probably about on par as if i would have done custom php/sql. Resource use for django hasnt been an issue, I dont think I could blame the framwork for this if i had issues. I dont see general purpose side effects in Django, I find the building blocks small enough to easely do stuff exactly the way i want. And the abstraction level isnt at all a problem, its a releif! :) As for css frameworks - i dont beleive in that, better make some general css files to start from and have methods in your head how to do certain stuff. JS frameworks - gotta love them, I also here have a problem seeing the situation when not to use it in new projects. Jquery weighing in so low, thats a non issue and its so easy you dont even need your eyes open writing code using it.
Great post! I submitted it to Digg as a thanks. :)
This is a bit late (prob. no one will ever read it), but the usual statement of what-is-a-framework-vs-what-is-a-library is that a framework calls your code as part of its operation (i.e., it drives you, you don’t drive it), while your code calls a library (you drive it, it doesn’t drive you).