Thursday, June 22, 2006

Frameworks versus Libraries

Benji Smith, who is famous for why he hates frameworks, has very good points.

(Go read that.  it's important, and it'll make you a better person.)

His points about the problems with abstraction in frameworks are good, and well taken.  (at least, they're well taken by me.  It seems like the Java EE folks and the WS-* folks have a lot to learn from him.)  But a couple of posts down in that thread he comes back with some more ideas, one of which is one I really wish I'd thought of first:  the difference betwen a framework and a collection of libraries.  The difference is this:  your code encloses its libraries, but is enclosed by its framework.  This has a couple of consequences that are good for framework vendors, but bad for developers:

1. frameworks are mutually exclusive.  If you're using Java, you're by definition not using .Net; if you're using Struts, you're not using JSF; if you're using Google Web Toolkit, you're not using Atlas; if you're using GTK, you're not using QT.

2. frameworks impose lockin.  In order to stop using a framework, you have to get your code out of it, a process that may or may not be possible and certainly won't be easy.  In order to stop using a library, you have to take the library out of your code.  Depending on how heavily you're using it, that might be hard too; but in its hardest case, you still don't have to "get your code out of" a library. 

The difference is crucial.  The barriers to exit are much, much lower with libraries than with frameworks.  Developers of libraries have to be a lot more humble than developers of frameworks do; we talk about "J2EE applications", but not about "cURL applications" or "pango applications".  Given the choice between a framework and a library with equivalent functionality and ease of use, I'll take the library every time.

Of course, libraries and frameworks still have a lot of similarities.  They're both bits of helper code that purport to do something complex or common well, so you don't have to hand code boring or tricky things.  They're programs like everything else, with a tradeoff between features and complexity.  They have their bugs, and their idiocies.  And there are certainly times when it makes sense to use a framework; Ruby on Rails or PHP or JSP or ASP is better than coding servlets or CGI programs, for the majority of the things I want to expose on the web.  But when you evaluate some helper code, be aware of the difference between a framework and a library.  And when you're *writing* helper code, for gods' sake please write a library.  Frameworks are much harder to get right.


Post a Comment

<< Home