Ian Bicking: the old part of his blog

Re: Handling a Diversity of Frameworks

> Adopting a framework is less commitment, and moving to a different framework no longer requires anything like a full rewrite.

The idea of switching frameworks easily just doesn't make sense to me. For the sake of this comment, I think a framework has two parts:

  1. A framework lays out a set of interfaces that people can plug into. When people choose Aquarium, Aquarium lets them swap out Web servers, how they do their URLs, how they do their sessions, etc. All of this is tied to using simple API's that Aquarium provides, and then swapping in new pieces that implement those API's. Those API's are fixed so that what implements those API's can change. You can't have the backend and the API's changing at the same time, nor should you need to.
  2. A framework often lays down a methodology for solving a domain of problems. For instance, Aquarium lays down the way I think many Web applications should be developed. For instance, it distinguishes controllers from views. Changing from having controllers and views to something else, such as having just views and other stuff (like Zope) can never be easy. It requires a rewrite.

So if you want to change frameworks all the time, the API's have to be overly simple and it can't suggest a methodology. What's the point? ;) You're better off just providing a library for whatever real functionality you provide and not calling it a framework at all.

(That's just my $0.02. Keep up the good work :) )

Comment on Handling a Diversity of Frameworks
by Shannon -jj Behrens