With OpenOffice 3.0 (the AJAX edition) in the works, I thought I'd join the bandwagon and do a little more with AJAX. So I have a dilemma. Much like in the python world (where it is really easy to implement what you want) where there exists many slightly different flavors of wheels (with new ones comming out too), there also seems to be a plethora of AJAX frameworks. And it appears that new ones are reported pretty frequently.
I've messed around with CPAINT (in fact I ported version 1 to python available here with the AJAX spellchecker), and SAJAX. But I was blown away during OSCON by Alex Russell's Dojo (he seemed to know his javascript inside out, and I found things like graceful degradation and js packaging quite innovative). (Ok, prototype is cool too and was featured at OSCON).
But then there's mochikit, which seems to be pythonic, documented and tested (all good things). Plus it's being adopted by at least one fast moving project (or meta-project ;)). And I've heard good things about open rico too.
So, how to decide? The friendly folks over at OSAF have the beginnings of a comparison. I'm currently split between Dojo and Mochikit. If anyone has used these or others and has strong opinions please feel free to comment here (or point me to where google has not). I'm looking for anything more substantive than the OSAF comparison. Thanks.
My (mini) interview with MochiKit creator (Bob Ippolito) posted with his permission:
I would like to solicit your opinion on what makes MochiKit the library of choice.
B: Well obviously I'm biased here, because I wrote it. I wouldn't have written it if the other libraries were suitable for the kind of code I was writing.
Ok, so the other libraries weren't suitable because....? Because of the code? Because of the app? I'm not trying to be annoying, I think it's interesting to see why people "re-invent" the wheel. Why not contribute to say dojo or openrico so that they are suitable to what you were doing?
B: Dojo didn't exist in a usable form, I don't think open rico hadn't been released yet. Neither have very complete documentation, and it was easier to write my own than to read someone else's source and figure out how to use it. Prototype did ugly things that aren't compatible with (most) other JavaScript libraries and had no documentation or tests, so I threw that right out the window andeverything that depends on it.
If I were starting today, I'd probably contribute to Dojo. I'm not interested in dropping MochiKit for Dojo because MochiKit does everything I need and Dojo doesn't. I talk with those guys prettyoften, and some of MochiKit will probably end up in Dojo at some point... but I'm not the one that's going to be doing that work.
MochiKit doesn't try to do everything (like Dojo), but the functionality it has is very good. I encourage people to use other libraries with MochiKit if you want functionality that is available elsewhere.
Could you elaborate a little bit more about what it does and doesn't do? Why did you include/not include the functionality in MochiKit?
B: I've talked a bit about that on my blog. The documentation covers what it does and doesn't do; MochiKit's public API is completelydocumented.
My mini-interview with Alex Russell (of dojo fame):
What makes Dojo the library of choice?
A: I'm going to cop out on this one and mention that you don't have to choose between Mochi and Dojo. You can use them together. In fact, BobIppolito has added Dojo package system hooks into Mochi so that you can load (and build) Mochi via Dojo.
That said, Dojo has some situations in which it makes more sense than other options. Namely, if you're looking to develop UI components thatwill be re-used in an application and don't want to do DOM manipulation by hand, Dojo is the best tool for the job. Past that, Dojo provideshigh-level abstractions for all kinds of stuff that an Ajax-style app might want to do, including an event system that makes the differencebetween DOM Events and normal function calls dissapear and an IO API that makes the whole "Ajax" bit of ajax much easier. The animationlibrary is pretty great too.
And did I mention that we have a WYSIWYG editor component? And it works on Safari.
Past that, it sounds like you're familiar with the advantages of things like the package system, etc., so I won't bore you with those.
What docs we have are at:
What do you provide that others (openrico/prototype) don't?
A: It's kind of hard to even remember all the things that distinguish us. The back-button fix, the event system, and the widget system spring tomind though.
OpenRico is based on prototype, as is scriptaculous. They both take the core stuff provided by Prototype and extend it in some way. Neither of them have a coherent widget system (although scriptaculous is trending that way), and neither are designed to degrade or integrate with markup the way Dojo is. Perhaps Dojo's defining feature today is that we are markup-driven both in how you write widgets and in how you declarethem.
Instead of trying to glue a DnD system onto an animation library and then try to combine it with some other widget or "Ajax" system, you canjust pick them all up in one place (Dojo), and safely pick only what you need. And we come with components like combo-boxes and rich- texteditors out of the box.
Want a WYSIWYG editor? it looks like this in dojo:
<!--somewhere in head-->
<script src="path/to/dojo.js"></script>
<script>dojo.require("dojo.widget.Editor");</script>
<!-- ... somewhere in body-->
<div class="dojo-Editor">
+ ...
</div>
And when your document loads, the
will get replaced with a Dojo Editor control (you could also speicify "dojo-RichText" for an editorwithout chrome).Where all the other toolkits fall down, and where we've invested significant effort, is in deploy-time optimization. Our compressorsystem is seamlessly integrated with our build and package tools. Most of these other tools make it an "all or nothing" affair, and if you want to build a single deployment file, you'll have to call it a different way. The Dojo package system make it transparent. You just build, point to the new build, and it all Just Works (TM).
What is the history of Dojo?
A:Dojo started as me contacting all of my friends from the DHTML community (I did netWindows before Dojo...I've been at this a long time) and basically said "if this stuff is gonna fly, we need a single toolkit. Lets stop re-inventing the wheel". We started a mailing list, got aname, and got down to coding. That was about 18 months ago.
At the time, there were several larger toolkits that people donated, namely Burstlib, netWindows, and f(m), and we set about to pick just the best pieces from each and make a coherent whole.
When you started working on it, did other projects exist?
A:Not the projects you mention, no.
If so, why did you build your own?
That is, perhaps, a better question for all the other toolkit authors. I'm pretty sure that I've approached most of them about cooperation,but many have demurred for various reasons. We started as a consolidation project and would love to continue that consolidation should some of these fragmented efforts get tired of maintaining their own stuff and re-inventing what everyone else has already done.
The Dojo comitters list reads like a "who's who" list of DHTML experts.