Re: Django and AJAX: Setting aside the conflict

[David Ascher]

On 11/16/05, Robert Wittams <[EMAIL PROTECTED]> wrote:

Not to fan the flames, but I think my position has been a bit distinct
from these:

3. There are requirements for the bundled apps to make use of extensive
JS functionality. If we don't bundle an existing toolkit, we will end up
inventing a new one, or selling the bundled apps short. Not making a
decision does entail a cost.

A related one is: when looking at building a webapp these days, one must consider both server side framework choices and client side toolkits.  Anyone who'se put together products from several technology pieces knows that some go together well, and some don't.  In the case of Ajax, it strikes me that there are pieces of the story where it'd be nice to know what the "recommended" approach is.  Django (and Rails, and Dojo) are in part going to be successful because they free users from choice.  So saying "whatever you want" isn't actually what most people want to hear (myself included).  I want to trust experts to tell me what technologies I should bother learning/investing in, in particular those that will save me time/effort.

I've been following Dojo for a while and Mochikit more recently, and while I have no doubt that Mochikit will interface w/ Django just fine, I suspect that with a little bit of work, Dojo+Django could make for a very compelling solution, for example in autogeneration of client-side validation code drivene from the Django introspection capabilities.

I also suggest that from a competitive marketing analysis, it'd be good to figure out which of the Ajax capabilities that Rails claims make sense in Django.

Regardless, this all seems tempest/teapoty. 

Congratulations on the 0.90 release, btw!

--da