Georg, I agree with you that we should approach this issue by building just what we need in a practical and incremental way,
so +1 for that. But are we sure we want to build our own javascript framework from scratch? There are two opposing forces here: the effort to develop and maintain our own framework (and make it at least as good as the competition in terms of usefulness) vs the effort to track the moving target of another. Obviously so far, Django has tended to choose the former, and I'm confident that the unity we gain from building our own ORM rather than adopting SQLObject for instance, is worthwhile. We clearly have the talent and the focus to do a good job there. When it comes to javascript I'm not so sure where the balance lies. It seems to me that it's not quite so core to Django - it's not necessarily where we should be expending lots of effort. I think if we choose a third party framework, it should be as stable as possible and as simple as possible - currently Dojo seems to be changing quickly and getting larger and larger (I know it is componentized, but the point is, how complete should our integration be?). If as Eugene says, we're not interested really in visual effects, then perhaps we should choose something smaller, like prototype.js or tw-sack.js (just 4 lines of js to retrieve an html fragment from a URL and replace an element with the the fragment). Just my 2p.
