January 03, 2006

Notes while researching AJAX libraries

I realize I'm behind the times learning about AJAX but I finally have a possible reason to use it. ("Possible" because what little webapp work I do now is as an admin front-end to a Spring-enabled server with web and data services.)

Unfortunately the internal team working on webapp framework upgrades hasn't picked an AJAX framework -- I was hoping they'd done all the hard work already! So, time to get my learn on.

The basic concepts behind AJAX are a piece of cake. I get treating the page as a DOM, async requests, callback handlers, JavaScript prototypes and its special brand of OO, XML-or-JSON data as RPC return value, registering special backend handlers to respond to the AJAX requests, etc. No problem.

My needs for this are fairly simple:

  • Stick to the front-end stuff. I don't want a do-everything library, they're always a gigantic PITA to debug and therefore make me pre-emptively nervous. Plus, I don't like being tied down to a particular backend framework just to make the front end work, particularly for a front-end library that's supposed to consume generic messages. This also means I don't want to do anything on the back-end that's synced with the front-end, even if it makes my life easier. Creating dispatch tables to do this myself is not a problem.
  • Typical compatibility stuff (cross-browser DOM manipulation, different XMLHTTPRequest implementations hidden behind abstraction, etc.)
  • Don't dictate an XML message format. If a library makes it easiest if you use top-level element 'foo' and child 'bar' with your data, fine. But make it possible for me to use something else: again, one of the supposedly attractive features of this is the generic messaging. The server's job is to deal out data, not to format it to make all the different clients happy. That's the client's job.
  • Up-to-date docs with examples. If something is really, really sharp then this need can be glossed over, but without the docs it difficult to tell if something is really sharp: nice Catch-22. We can break out of the Catch-22 if someone I know and respect recommends it: word-of-mouth almost always wins.

So I googled around a bit and found the following resources from:

I'll just list them here and (hopefully) write later about which once I decided to use.

Frameworks

dojo

This looks genuinely interesting and it seems like the authors have put some time into designing the libraries. After browsing around a bit docs are fairly weak for what it does. But it seems like a contender.

prototype

I've heard of this before (is Rails using it?) but the admission in the README that "Prototype is embarrassingly lacking in documentation" is discouraging. But wait, someone seems to have written a separate guide which is encouraging. (Possibly even more encouraging than if the original author wrote it, since it means that the concepts are getting digested by another brain before being laid out.)

I really like the $() and $F shortcuts, very smart. Why would anyone complain about these? If they're not cost reducing I don't know what is.

...uh-oh, it looks like maybe the Ajax object wants its XML in a particular format ('ajax-response' top-level element in example under 'The Ajax Object'). Under that it looks arbitrary, so maybe it's not so bad...

...the "Developers' Notes" reference looks useful and shows lots of use-case oriented objects and methods. (Insertion and .Before, .Top, .After? Neat.)

After reading a number of other sites (some of which I didn't mention here), Prototype came up a lot as a dependency. This is a good sign.

External Prototype docs:

Behaviour

Not an AJAX toolkit per-se, this just allows you to register events much more cleanly. Looks pretty simple and easy-to-use.

script.aculo.us

Silly name, but pretty sharp. Seems to confine itself solely to front-end effects and uses Prototype for the heavy lifting.

Documentation at first glance looks decent, but it's in the form of a wiki. That's not horrible but like most people I like having everything offline and in one place.

MochiKit

Great docs! And tests! Support for JSAN!

This looks great and seems like it could be used in favor of the scriptaculous/Prototype combo except the set of visual effects is tiny. Actually it's one and a pretty small one: rounded corners. Maybe there are libraries that build on top of this?

The online demos are great, but it seems like an awful lot of code to do client-side sorted tables. (That could just be my ignorance talking though, since I don't have much experience with it.)

They stuck in the $() shortcut, cool.

DWR
(Direct Web Remoting)

Good docs, but it's tied to server-side technology. It's very Spring-like in its approach to un/marshalling.

SWATO

Seems like it requires both client- and server-side components. I appreciate that it can Spring for this, but that's still no good. Sparse documentation.

CPAINT
(Cross-Platform Application Interface Toolkit)

Good docs, a rarity. Unfortunately, it's (a) a do-everything framework, (b) explicit about the XML format it wants from the backend. Not for me.

It also seems to want the backend to serve it HTML which it can just put in the right place. I guess it's useful, but pretty limited.

Taconite

More response documents as its own format, more formatting in the response.

Sarissa

While I like the name because I had a crush on a girl named Marissa in high school, and it is client-side focused, this focuses on XSLT which seems like jumping out of the frying pan and into the fire.

Rico

Sharp looking page. Let's click on 'Documentation'...

This page is being expanded. For now here are a few guides and tutorials.

Next!

ZK

WTF? This looks like it's all server-side, serving up XUL. Feh. (Plus, they don't tell you the docs on the front page are all PDFs. Annoying.)

Next: Parsing XML with JavaScript: anything easy?
Previous: Which hogwarts house are you?