Ajax explosion

Yep, I have exactly the same dilemma and have come to the same choices. I have a friend who liked Open Rico over Dojo Toolkit, but I really have a good feeling about Dojo Toolkit. I've been to a talk from one of the developers. I read the author of Mochikit's blog, and I can tell he's wicked smart. However, I'm suspicious of the maturity of programmers who spend so much time bashing the work of others. Also consider that an XMLHTTPRequest wrapper is probably the least interesting feature in these libraries! Please update us with what you learn!

Check out: http://sourceforge.net/projects/sarissa/

3.2.3- I've heard of Sarissa, why should I use it over any of the libraries I've mentioned? What does it do that the other libraries don't?

Use both, they're complementary.

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 and everything 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 pretty often, 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 completely documented.

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, Bob Ippolito 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 that will 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 provides high-level abstractions for all kinds of stuff that an Ajax-style app might want to do, including an event system that makes the difference between DOM Events and normal function calls dissapear and an IO API that makes the whole "Ajax" bit of ajax much easier. The animation library 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:

• http://dojotoolkit.org/docs/

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 to mind 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 declare them.

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 can just 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-text editors 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">

• ...

And when your document loads, the <div> will get replaced with a Dojo Editor control (you could also speicify "dojo-RichText" for an editor without chrome).

Where all the other toolkits fall down, and where we've invested significant effort, is in deploy-time optimization. Our compressor system 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 a name, 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.

I like Mochikit, a lot. Dojo was a little too big and did a little too much for me. There's very little of Mochikit that I don't find useful. Mochikit doesn't have a lot of the visual effects that other toolkits have, but it has a lot of elements that make Javascript programming in general a lot easier. And if you're coming from Python and are familiar or comfortable with the more Functional style of Python (map, filter, zip, itertools, etc), it's a very natural fit.

And the documentation on MochiKit is top notch.

So for me, it's just the right size. And it works with Dojo if you need to expand. Part of me is afraid of some of these new JavaScript effects becoming the new blink or new flash - things that look cool (well, in the case of flash) but often start getting in the way or overused. I started with some of the flashier Prototype.js and Scripaculous libraries, but since dropped both of those in favor of MochiKit and a few simple effects (like highlight). That's worked better for my situation.

I haven't been too impressed with OpenRico. Many demos don't seem to work with Safari 1.3/2.0, whereas most other toolkits I've evaluated do support it.

If you are targeting the Firefox browser, and you like the Twisted framework (http://twistedmatrix.com/) then you might want to take a look at Nufox (http://trac.nunatak.com.au/projects/nufox). It allows you to build XUL apps with no javascript knowledge in a very pythonic way.

A correction to the original AjaxLibraries list. There is a SAJAX Java port. See: http://absinth.modernmethod.com/sajax/forum/viewtopic.php?p=887

I get the feeling I would like the work in Mochikit better (they're my kind of people!), but that Dojo has a bigger community, more features, and supports more browsers. This is based on:

http://wiki.osafoundation.org/bin/view/Projects/AjaxLibraries

Since Dojo is already a collaborative effort, it sure would be nice if the Mochikit community could apply the cool things in Mochikit to Dojo (docs, tests, functional programming). I think that would be a great service to us all.

Shannon,

Dojo already supports lots of functional programming constructs in addition to robust AOP support (via the event system). We also run unit tests on the toolkit, and we're portable enough that our unit tests run at the command line.

That said, Bob and I have figured out some ways to expand our collaboration in the future. Stay tuned = )

Regards

I blogged about this. I really like MochiKit, but right now, I'm using Dojo and I like it. It just had more of the things I needed, including the event system. I won't hesitate to use both, however, and I'm on both mailing lists.

don't want to spoil any party, but... if dojo is soo good and soo fine, why don't they put some damn examples on their page?

hi, i am working on a project with Barracuda framework, i want to use ajax , so pls tell me which of these ajax packages is best

Ajaxian.com reports there are now over 200 AJAX frameworks. It can be daunting for the AJAX newcomer to know what to go with. I personally went with Prototype + Scriptaculous and have never looked back.

Dojo already supports lots of functional programming constructs in addition to robust AOP support (via the event system). We also run unit tests on the toolkit, and we're portable enough that our unit tests run at the command line. I'm agree with you. Keep up the good work. Greetings

thx for the great stuff. keep your nice work!