Ian Bicking: the old part of his blog

Handling a diversity of frameworks comment 000

While I agree somewhat that the sheer number of frameworks isn't necessarily a problem, I don't sense lock-in or incompatibility as being a huge stumbling block for many. I still think it's a business-like concern over support (i.e. documentation, books (eventually) and number of other users of the software) that is most people's concern.

If you can switch frameworks reasonably easily (and incrementally), then you can follow support and popularity. That's why I think lock in is a big problem. That said, in practice lock in isn't terrible right now, with one notable exception (that starts with a Z), but it's still more than it should be.

That said, if it happens on a shared spec like WSGI and your other efforts, that's even better. But I suspect that will be resolved by a large-visibility project choosing to implement it rather than the project needing to for its own success. i.e., top-down as opposed to bottom-up. Just missing the obvious top right now...

I think (?) that Zope 3 probably already runs on WSGI. When the Twisted people asked Jim Fulton what it would take to get them to use Twisted instead of their Medusa fork, he asked them to do it via WSGI. Twisted web2 (which had a 0.1 release recently) included native WSGI support, and Zope 3 should at least come along soon. I doubt Zope 2 would be that hard either, though what I'd really like is a Zope 2 WSGI Server Product, so that you could run WSGI applications under Zope. Really I should just stop talking about it and write it, because it shouldn't be that hard.

Comment on Re: spit & polish
by Ian Bicking

Comments:

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.

# 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