Ian Bicking: the old part of his blog

Re: Handling a diversity of frameworks comment 000

I should expand on the importance of being able to switch:

An environment where people can move from one framework to another will allow a real Darwinian process, and the emergence of a smaller set of "winners". Right now frameworks linger on forever, because there's no honest way for them to die. Either the developers abandon their users -- many of whom are often clients who trusted the developer's original choice of framework -- or the project keeps going and further development continues on it. Neither is good; either you are bad to your customers, or you create a partisan environment where each group of developers works in isolation to create the same set of features in their different frameworks.

The coupling of typical frameworks makes this worse. It's hard to be a polished framework when you have to implement a large number of features. As a result, frameworks typically implement a few features well, and some features poorly. As a result the selection process is haphazard, because you have to decide which features are important to you (and you don't really know), and you have to accept compromises in other features. With a decoupled stack, you can choose the best piece for each level of that stack. Sometimes there will still be vague choices -- different valid quality implementations, which appeal to different segments. But I think at each level there will arise a small set of choices, each with real reasons for existing even in the presence of other implementations.

Comment on Handling a diversity of frameworks comment 000
by Ian Bicking


You are of course right on the huge value of being able to switch - or "evolve away" from a specific framework. As seen in the Java world with some people moving away from Struts to more recent setups like Spring, JSF, [today's new favorite], etc., but not needing to move it all at once.

I guess I was loosely speaking more so of the possible reasons for thriving/dying of contenders. Most likely both parts are needed: not being locked-in at a lower level will allow more dynamism in the upper levels, which should lead to a few "obvious choices" as you point out [and I tried to point out as needed to really expand the visibility of pyweb stuff].

Perhaps akin to having your living room furniture bolted down and/or integrated into your flooring - requiring tearing up the floor to change things [current scenario], and having all your furniture on wheels on a nice smooth floor - easy rearrangement [planned]. Alright I'll stop killing analogies now...

# ToddG