AJAX vs. AHAH

A few weeks ago a few folks discovered the REST section of the microformats wiki, which discusses “how to optimally use Microformats as the encoding for REST web services”, but has grown to include broader discussions of applying microformats principles to both protocols and javascript techniques.

One of those principles could be rephrased as: Why use XML when (X)HTML will do?

Perhaps another could be rephrased: Why bother with parsing/transforming when you can just get the data in a presentable format? After all, we all know that less code is better.

AHAH (Asychronous HTML and HTTP) is the result of applying both of those principles to the incredibly Web 2.0 buzzworthy AJAX. Strictly speaking, AHAH is simply a subset of AJAX, albeit a subset that openly de-emphasizes the X in AJAX.

…instead of grabbing arbitrary XML and processing it on the client-side with Javascript or XSLT and inserting things into the DOM, you just grab bits of (X)HTML from the server and inject them directly into your page. So, the client side does much less logic and merely needs to say “replace the content in the element with this ID with the (X)HTML at this URI

So if you’ve been wondering what this AJAX stuff is about, take a look at AHAH, you might find it gets you 90% of the hyped user interface advantages with only about 10% of the hype (and effort for that matter). That’s the kind of 90/10 rule we like around here.

17 Responses to “AJAX vs. AHAH”

[...] Is this what I’ve been doing? Asynchronous HTML And HTTP (AHAH). AJAX without the “X”—Reader’s Digest: instead of sending XML, send XHTML snippets to directly output to client (i.e. process the transformation on the server rather than the client). I can see the benefits; some of what I’ve been doing with my latest project is that exactly. I can definately see the advantages to that. I think it’d be most useful when you only have a small amount of information to display. [...]

Just wondering, is there an interest to use microformats in regular HTML pages. I just played the game with hevents here :http://www.esterel-technologies.com/news-events/events/events.html
but cannot generate .ical files as xslt needs an xhtml input. AFAIK, Javascript does not helps either, as it cannot generate files.
The only thing left, is to use php to generate the ical file, but where is the interest of the html markup then ?

The potential problem I see with sending actual structured information is that it leaks your structure and presentation into your server-side code. The end result, without careful planning, could be a mess of code that’s hard to work with. However, with careful planning I could imagine some setups which work well with AHAH.

I recently created a simple CMS system for a client using AHAH. I, like many others, was new to this technology and came out hating it. Why, I left out the XML.
When managing relatively simple content block you have several separate fields. These fields must have a unique id to perform innerHTML. You also need to define the region as editable, and perhaps many other qualities. There may also be status messages, progress bars, disappearing/reappearing links, etc.
Using innerHTML as is common in AHAH apps makes it hard to remove that status message div. Even if you get that working how will you tell your javascript functions what is getting updated? Using arbitrary delimeters? How is that going to jive with sharing content across different sites and frameworks?
My point is, if your making a complex web app that is also accessable at some point you’re going to have to use the DOM anyways. innerHTML will only get you so far. XML helps you deal with some of the complexity of this asynchronous web. Without it things will get very frustrating, very quickly.

I agree with Chad. Too much markup, harder to parse, sub-optimal, arbitrary (presentation) markup over often ambiguous data structures (e.g. as far as I can tell, a definitive post-Vcard schema for structured contact info hasn’t been adopted yet (FOAF does not constitute a business worthy contact management schema)).

The advantages for presentation are mitigated by the absence of CSS namespace. A big problem when you’re shoving styled, syndicated content into a styled container.

AHAH seems to be a dodge. A way to make records technically structured when you know that you’ll never really have to deal with the structure.

Most browsers handle the DOM well. It’s easy to “parse and present”. I’d rather see more effort put into formalized, useful schemas and, with luck, a browser embedded, “scriptable” equivalent of Jena (an RDF datamodel, Jena is to RDF what the DOM is to XHTML) and SPARQL (an RDF query language).

If you pull xml only and do the transformation on the client you free the servers from the transformation. Also, if you pull data and style separately, you can change style inmediately without need of pulling data again.

What Mr. Clifton said. I really don’t see the need for this kind of adversarial attitude between innerHTML and “the DOM Way.” XMLHttpRequest isn’t even part of the DOM or any other standard; it’s a DOM-compatible Microsoft hack (circa IE5) that’s gained widespread browser support.

That doesn’t necessarily mean we should abandon the DOM in documents and applications that use XMLHttpRequest, but we should acknowledge that we’re starting out from a rather hinky place to begin with. It certainly seems like a silly thing to establish dogma over.

It’s strange to see AHAH promoted on a standards oriented site, where they should know that the innerHTML property is not a web standard! The fact that it’s implemented by browsers doesn’t make it right to use it. The W3C had a good reason to leave this one out (and XML is probably it).

[...] The difference? The X in AJAX is for XML. More often than not you can grab chunks of text or javascript from a separate file without going through the hassle of messing around with XML. Here’s a better description of AJAX vs. AHAH. [...]