Today I discovered that I missed very interesting Django/Ajax-related discussion on #django. Specifically MochiKit-Dojo comparison was discussed. I know it is hard to talk about Dojo, when documentation is lacking. Let me present my take, based on some experience with both toolkits from prospective of simple user. I'll try to be objective.
MochiKit. 1st and foremost: it has the best documentation of all Ajax toolkits I saw (see http://www.mochikit.com/doc/html/MochiKit/index.html). Test collection is comprehensive as well. MochiKit builds on Python whenever it is possible. You can see Python in many objects provided by the toolkit. E.g., Async module (it wraps XHR) is built after Twisted and provides Deferred, which is very nice. Out of the box it provides GET verb. You can do POST too, but it requires some manual work: basically you should build post data by yourself and work directly with XHR. Fear not, there are some useful string manipulation functions, which can help. Iter module is derived from Python as well. There is DOM creation API, which is nicely done too. The only potential problem is performance, which can be critical, if you want to create big DOM tree from your code. It is not a limitation of MochiKit, it's a limitation of approach --- unfortunately modern browsers work faster with mundane innerHTML. At least this is my experience. MochiKit provides a comprehensive set of string formatters, which is very handy too. Despite some people's opinion, MochiKit has exactly 1 (one) visual effect: rounded corners. IIRC it was donated and somehow got included. The lack of visual effects is intentional: MochiKit focuses on data processing and DOM creation. Basically it follows prototype.js strategy, which doesn't provide visual effects at all (0/zero), relying on independent libraries like script.aculo.us or OpenRico for visual glitter. I don't know, why Bob decided to include rounded corners, but they are here, they work, they are useful as part of visual design. MochiKit is fairly neutral, it may be used with other visual effect libraries. Another thing, which I like in MochiKit, is consistent JSON support, which simplifies a lot of things. Basically JSON notation is a simplified declarative JavaScript code, which can be "decoded" using eval("("+json_data+")") (see http://www.crockford.com/JSON/index.html). It makes programmer's life easier. Try to do it with XML. ;-) MochiKit makes it easy to "read" JSON from server, and to serialize your JavaScript object to JSON for server processing. I really dig it. All modules are in separate files, so you can select what functionality you need. Support is done by Bob Ippolito --- the creator of MochiKit. Having a sole developer/maintainer makes MochiKit more consistent. It's easy to write him a letter or ask him in MochiKit support group. You can find him there, or in Dojo group helping people, or in TurboGears answering questions --- yes, some other major web framework has already selected MochiKit as part of its stack. Dojo. Dojo covers much more than any other Ajax/JavaScript toolkit I know of. Obviously size of Dojo's source code is large than other major toolkits. In order to overcome this problem Dojo has elaborate modular compression / packaging / linking / loading system. It works like that: 1) Every module declares its dependencies and what it provides (import/export declarations). 2) It is possible to declare your dependency on a single file, all files of a directory, or any mix of those. 3) When you load dojo.js, it loads very small bootstrap code, which can load other modules dynamically. This process is fully automated. If requested module has some unresolved references, loader will continue the process. Once it is loaded, it will be reused for subsequent requests. It means that if your web page doesn't use some functions, they are not going to be loaded. Simple stuff loads almost instantly. Obvious downside of dynamic loading is a potential to produce a lot of small requests, which can be a problem due to network delays. In order to combat it, Dojo has a packaging system. It is trivial to specify, which modules are required, and build a custom "profile" of Dojo. In this case your custom dojo.js will include a loader _and_ requested modules. 5 profiles are pre-built: Minimal, Browser I/O, AJAX, Event, Event + I/O, and The Kitchen Sink. AJAX profile is about the size of MochiKit. If you use modules, which are not included in the profile, they will be loaded dynamically. So it doesn't really matter, which profile to use. The difference is in loading time, which depends on application. For one of my projects I created a custom build, which included just the stuff I need. I discarded the rest to conserve memory, because I know that the rest is never called. Basically all unused components can be easily removed --- Dojo has true plug-and-play modular structure. Optional source code compression can be used to reduce size as well. MochiKit uses Dojo compression/packaging system. dojo.io.bind (Dojo's XHR wrapper) is more elaborate than MochiKit's offering communication-wise. It handles GET and POST using simple dicts to specify what you want to send and how to handle it (see http://dojotoolkit.org/docs/intro_to_dojo_io.html for code examples). It is possible to specify an existing form, instead of actual content. In this case the form (its fields) will be submitted using dojo.io.bind. I like this feature because it allows to embed Ajax in existing apps without major surgery. Multipart POST patch (written by yours truly) is pending. It can handle files formed directly on the client using JavaScript as well as regular data. Another remarkable part of Dojo is the widget system. It allows to separate your widget into (up to) three files: JavaScript module, optional HTML file, and optional CSS file. HTML file and CSS files are templates, which are used by widget system --- very Django-istic. In your template you define points of attachment. No JavaScript code goes there. It is very easy to use widgets. The simplest way is to mark up your widgets in HTML file and Dojo will instantiate them for you. There are several ways to do it. I prefer this way: <div id="AreYouReallySureDialog" class="dojo-dialog">...</div> In this case "dialog" widget is going to be instantiated. It can use existing content, it may create its content dynamically, or Dojo may use templates for substitution. BTW, widgets may contain another widgets. It is possible to build a super-widget out of simple widgets. >From my experience it is easy to create completely self-contained widgets with clean mark up. The best thing is you don't need to write spaghetti code, and hook into events in different places. Finally I was able to make HTML files, which are fully dynamic but don't have a single line of JavaScript code or extensive mark up. Dojo event system is another marvel. It's modeled after AOP concepts and allows you to do a lot of nifty stuff. E.g., it is possible to hook your event to ... calls to some object's method. In canonical AOP fashion you can specify when do you want your hook to be called --- before, after, around. It allows to order your pre- and post- processing in a flexible way. Obviously all browser events are supported seamlessly. Multicast events are supported seamlessly. Custom events with parameters can be created. All technical event-related code are completely gone from application --- you operate in terms of "connect" and "disconnect". See details here: http://dojotoolkit.org/docs/dojo_event_system.html I spent a paragraph writing about events because they are extremely important for widget writing. Who tried to do it will understand me. Dojo event system makes your code clean. From my experience with Dojo events almost all widget code handles business logic instead of mundane plumbing. Custom events are useful for messaging between components. It is a provision for communication between different widgets. It makes it possible to make widgets aware of neighbors. Dojo supports a lot of other stuff: drag-and-drop, curve-based animation, cross browser transparency, a lot of useful utilities, and so on. Additionally Dojo has a library of widgets. I counted about 35 of them. Not all of them are ready for prime time. I use Dialog a lot, played with Menu, ContextMenu, Tree, InlineEditBox, RichText, SlideShow, SplitPane, ColorPicker, and Time/Date pickers. They mostly work. :-) In any case working with Dojo I didn't have a need for other libraries. It was a stark contrast with, say, prototype.js --- I had to augment it with script.aculo.us and behavior.js plus wrote quite a few of my own support code. Other notable things: some work was done on SVG. I didn't try it but apparently you can use Dojo in SVG. It sounds interesting. Finally we will have some nice charts, which will be a killer app for IT. In another interesting development Dojo people established (semi-)official contacts with Mozilla people. I hope it will improve both Dojo and Firefox. Now lets talk what's bad about Dojo: 1) Documentation is not even close to MochiKit's one. Mainstream stuff may be documented but I dig into source code a lot for less popular features, like MD5 calculation. Fortunately a lot of simple test files are available practically for all modules. 2) Not everything is properly tested. It means that when I release my code, I have to test it with all available browsers to make sure it works as intended. When it doesn't work, the culprit can be my code, but it can be a bug in Dojo's code as easily. 3) Dojo supports XML and JavaScript but doesn't provide direct support for JSON --- I have to use eval("("+json_data+")") "conversion, when I need it. Dojo is improving on daily basis. Its support group is very much alive and questions are answered by core developers in timely manner. SVN and Trac are available, documentation is in ReST files --- the setup reminds Django a lot. But they have more core developers. :-) It is nice to do open source being sponsored. :-) MochiKit and Dojo. MochiKit and Dojo are friendly to each other. It is possible to use them both. AFAIK, there is a pact between them, which allows MochiKit to use Dojo parts, and Dojo can lift stuff from MochiKit at will --- Bob is all for that. Sometimes people talk about merging these two frameworks. Bob Ippolito said that he doesn't mind eventual merging, but in the near term it doesn't look feasible: while MochiKit has fewer coverage feature-wise, it is much more mature and more stable. At the moment development focus of both toolkits is different too. I hope it helps. I will be glad to answer questions. If you want to contact core developers, Bob Ippolito is responsible for MochiKit, while Dojo can be represented by Alex Russell. I can help to facilitate contacts with Bob and Dojo people, if it is needed. Thanks for reading my rambling post, Eugene
