Who Spilled The Beans?

That post about frameworks seems to have stirred up some talk, in large part, I'm sure, due to it having accidentally coincided with the the release of django -- one of the authors of which I just happened to have met at a party at my place days before (sorry Simon!)

At first it was quite exciting going through and reading everybody's commentary, but after a while I got increasingly worried that I was being painted as the "anti-frameworks" guy. There's so much more to me, you see, I enjoy long moonlit walks on the beach, throwing parties and harmonica. Oh, and I use frameworks all the time because sometimes their suck doesn't outweigh their useful.

One of the first responses I ran into was over at lesscode where Simon said:

What he says about frameworks is certainly true - they always restrict you in some way. I suppose it comes down to a trade-off - does the productivity increase more than balance the loss of freedom? If not, then the framework isn’t worth having.

I think Simon really nails the lowest level decision there, many times if the framework increases your productivity enough it is worth the decrease in freedom. And many times the apparent decrease in freedom is really only a perceived difference, once you are well initiated into a particular framework (as long as it is well-designed) you start learning which things you can unscrew to fit your own pieces in without breaking the whole contraption.

Unfortunately most frameworks don't have very many places that aren't welded together by specific or short-sighted design. A framework designed without users is probably going to take some significant work to transform into one with private groups, a framework built without dynamic content in mind is going to be a tough noodle to wrap around XMLHttpRequest. That said, frameworks are starting to appear (Rails being one of the main examples) that take many of the tasks that a typical web developer is going to be attempting into account and I expect Django will be one of those.

Another rather strong point was made on bitworking:

Code wants to move. Code wants to be reused. Anything that slows down code from being reused, from moving around, is friction. Friction can come from many directions. For example, the license that code travels under can induce, or reduce, friction. Code written to a framework has higher friction than code built on top of libraries.

This plays into the not-written-here arguments as well. Your framework may handle sessions wonderfully because it was written for banks and needed maximum security, but if it takes me a week to hack the session code out of your framework it doesn't help me much when I don't want to write bank software. It becomes obvious that this is the case when you look at how many pieces of a framework are developed in-house. If they wrote their own code chances are it isn't going to help many people who aren't using their framework. Finding a decent chunk of session code and incorporating it into their framework, preferably enhancing it and giving it back to the community that originally wrote it, helps ensure that the code will be reusable without nearly as much friction.

One of the things that sat well with me about Rails was that its pieces were somewhat usable outside of the Rails architecture. The speed of development on Rails may depend greatly on the very defined interactions between all the pieces, on the set of variables that you can safely assume will be present when you start writing a template, but many of the pieces are thoroughly usable outside of the Rails architecture. The libraries in Rails were better than the systems other frameworks used and that is a big reason why Rails is successful, it feels more like a bunch of libraries strapped together than something like Zope ever will.

All that said, I intend to try out Django as soon as I get a chance, I'm excited to see what Simon and the boys have done with it, and if there is anything in there I can break out into a library you better believe I'm gonna try.

Oh and in light of all this framework vs. library talk, I figured I'd toss some docs on a bunch of the random libraries I've been using for rapid development of my own little scripts and release those to anybody who might be interested, maybe at some point I'll write individual posts for each one (probably once there is enough to them to be worth writing a post about) until then check the README.txt on each for an explanation of what it is all about. I cleaned these up a little, so hopefully I didn't break anything in the process, I'll be the first to admit I am useless when it comes to unit tests.

• ayb - A little base class that overloads the \_\_getattr\_\_ method in a way I commonly tend to, eventually doing quite a bit more of the common tasks I have to write.
• charcoal - Filtering tools
• clee - Fundamental command-line interfaces
• courriel - Super simple way to work with plain-text email
• flickr - Still rather undocumented, but works more or less like the upcoming.org API wrapper. I think it is way cooler than what is already out there, although it needs a couple minor updates for new functionality.
• funk - Misc functions + good times. It has a function called acronizzle.
• husk - Shell scripting shortcuts
• scribe - Slightly nicer logging
• sprinkles - Really easy plugins, probably the most interesting of this set after the flickr one.

Technorati Tags: rails, flickr, python, code, libraries, django, frameworks