Ajax toolkit roundup
When I was building StyleFeeder, I took the opportunity to survey the various Ajax toolkits out there with the hope of finding one that would suit all of my needs. Needless to say, I didn’t find one that could do everything. But I did learn a few things that I’ve been meaning to share.
First off, please realise that there are good toolkits out there that will happily integrate with whatever platform you choose to deploy on. Therefore, you should avoid making your own, unless you are one of the curious javascripters in the world who has the time and guts to get into all the cross-browser junk that you’ll bump into:
`if (top.bugRiddenCrashPronePieceOfJunk)
{
alert(‘Sorry, but your buggy, crash-prone\npiece of junk misnamed a browser\ncrashes on this simple script, believe it or not.\nTherefore I disabled it.’);
return;
}
top.location.href = parent.content.location.href;`
I’m using OpenRico, prototype.js and script.aculo.us. Why three toolkits, you ask? To work around the bugs in the various implementations and get access to features that aren’t uniformly available.
By far, prototype.js is the most stable thing out there. In fact, many toolkits require it as a dependency. It’s got a bunch of convenience methods and also forms the basis for easy DOM updating that we expect to see in Ajax applications. The documentation is sparse, but there’s a great start here available here.
I like OpenRico. It’s well documented and quite complete. I especially like the extension to the XML payload that prototype.js uses. This makes it very easy to update multiple parts of your web page with one response. However, OpenRico’s support for Safari is scant and I’m only using it for it’s rounded-corners support at this time. At one point, I got so sick of Rico’s finnicky behaviour for these rounded corners that I tried using MochiKit instead. I reverted back to Rico because MochiKit was screwing up my CSS layout. Well, maybe it was me. I really don’t know. But it was too much effort just for the sake of a few corners, so I ditched it. It’s worth looking at, though.
Script.aculo.us has a bunch of really neat effects that allow you to slide DIVs around, fade them out, etc. It’s been pretty good across browsers in my experience.
One thing that I tried to avoid as a design goal was toolkits that are tightly coupled to whatever I’m running on the server side. My feeling is that these types of toolkits will evolve in the most stable way over time since they’re not tied to the success of something on the server as well. I don’t mind a bit of “support,” but tight-coupling is just a Bad Thing in my camp.
Now, StyleFeeder is partially built on Struts and partially built on Cocoon. Basically, anything that emits XML or serves as an Ajax endpoint is running on top of Cocoon, because Cocoon basically excels at dealing with XML. Cocoon’s Flow makes it possible for me to hook into my backend Java code and return XML responses via JX using some really quick conventions and pattern matching in the sitemap. Essentially, I just write a single javascript method and I’m done. Pretty easy.
I highly recommend this approach for those of you who are thinking about building Ajax endpoints using Struts or Spring. Investigate it and I’m confident that you’ll find some compelling stuff in Flow and Cocoon.
Lastly, I discovered that building Ajax-style applications is easier than building Web applications The Old Way and you end up with more compelling results. Easier, you say? Yes, really. You can concentrate on writing little functions that perform one action to both the web page and the server instead of having to spend most of your time figuring out what was on the last page you displayed so that you can render it again to the browser. There’s a non-trivial productivity boost associated with Ajax applications, as long as you’re not knee-deep in Javascript nonsense. And using one of the various toolkits will save you from worrying about such minutiae.
You know what NIH means, right?