Personally I am leaning towards Dojo over MochiKit. Disclaimer: I contributed some code to Dojo so I may be biased. Upside: I know what I am talking about in regards of Dojo.
The reasons are simple: flexible AOP-inspired event system, thought-out widget packaging and management, versatile I/O. Additionally they have a compression-packaging system, which allows to extract and use only needed parts of the library. While it is clearly possible to add missing pieces to MochiKit, size of additions will outweigh MochiKit codebase. I think that MochiKit is small (==mean and lean) because Bob likes it that way. I don't think he will be eager to maintain our additions. Do we want to support them separately? In case of Dojo, Django-specific part would be a thin layer on top of Dojo. I think it is easier to add to Dojo from MochiKit what's missing. In fact they are already doing it: MochiKit's creator Bob Ippolitto is in the list of Dojo contributors, MochiKit supports dual licensing specifically to be compatible with Dojo, some parts of Dojo is/will be lifted from MochiKit. I think it is wise to talk to core Dojo guys (e.g., Alex Russell) about Django Ajax and explain them what we need. They are accessible and responsive. I am sure they will meet Django's requirements. Let's talk to Bob too to understand his position on that. Thanks, Eugene "Robert Wittams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Simon Willison wrote: >> >> >> On 14 Nov 2005, at 07:10, swrainey wrote: >> >>> Ajax is really hot right now and I could see loosing some developers >>> because it's not as on the forefront of the whole web 2.0 hyped up >>> junk. Ajax is more about usability than eye candy or at least it should >>> be. That being said. I know I can use ajax really easy inside of a >>> django project but will anyone choose another framework based on most >>> of the other ones having "ajax support". >> >> >> For me "Ajax support" really is pure marketing fluff - as far as I'm >> concerned EVERY web framework supports Ajax unless it does something >> truly moronic like refuse to let you output documents that don't have >> the standard header/footer template. >> >> That said, I know my way around JavaScript and prefer to write it by >> hand. I imagine there are many developers out there who don't and >> prefer having the framework do the work for them. The Ajax support in >> Rails is my least favourite feature, precisely because I like to have >> full control over how my JS works - but it makes a lot of Rails >> developers very happy indeed. >> >> At the very least, it is useful to have your framework make a few >> decisions/recommendations for you - things like which XMLHttpRequest >> cross-browser abstraction to use. I mould tend to look towards MochiKit >> for that kind of thing since it's more Pythonic than other JavaScript >> libraries, taking a lot of its ideas from Python features. >> >> One thing that would be very cool would be some built in support in >> Django for outputting JSON, which is a really neat format for sending >> data to and from the server via XMLHttpRequest. Maybe a custom template >> tag or filter would be useful here. >> >> I know the Ajax in Django discussion has been going on for a long time, >> but maybe it's time to take a closer look at it now that we're thinking >> about features for 1.0. After all, in the ultra competitive world of >> Web Frameworks marketing is important. >> >> Cheers, >> >> Simon >> > > One thing to note here: When we get rid of core fields, we are going to > want to use both ajax & drag and drop in order to implement ticket #13. > It would be nice to use some "consistent" framework to do this, rather > than picking random bits of javascript up from around the internet. > > Another thing to consider is ajax (pre-submit) form validation. So we do > have a need for goals within django itself which would best be served by > bundling a consistent js library set : its not just for users. > > I think that Mochikit is probably the best option, being fairly light > and pythonic. > > It doesn't include drag and drop or many effects - but it should be > possible to port anything we need from eg dojo or scriptaculous, and > maybe some turbogears people will beat us to it ;-P ). > >
