AxsJAX vs. Hijax

Google decided to Open Source yet another tool: a Javascript framework called AxsJAX, which aims to "add accessibility to AJAX-powered web apps". AxsJAX is already used in a couple of Google Apps, and is a set of Javascript tools that add accessibility tags to your AJAX webapp. This means that AxsJAX, spelled "AcessibleJAX" (to rhyme with AJAX), is only used if you have a recent web browser that has Javascript enabled and implements the drafts of W3C-ARIA, which, in other words, isn't an acessible framework at all. If you take into consideration the W3C Accessibility guidelines, you'll quickly see that depending on some yet-to-be standards (ARIA) or even in Javascript isn't being Accessible. Yes, you can add AxsJAX to your AJAX-powered webapp, but you must take into account that it will not make your webapp accessible... As a matter of fact I think it would be nice to have webapps using it, but on already accessible webapps.

Now, there's this silly idea that it's too hard to make an AJAX-powered webapp accessible. Developers talk about painful code to allow graceful degradation, and some are even crazy enough to actually prefer mantaining two webapps: one AJAX-powered and other AJAX-less. What's really wrong about this scenario is that it's pretty easy to design accessible websites, even AJAX-powered. Welcome to the world of Hijax.

Hijax (which is nothing more than a way to use AJAX) is just the way to design AJAX-powered websites. The steps are pretty simple:

• Design your webapp well


• Add all the AJAX you want by hijacking the requests

Now the thing is, what is "design your webapp well"? Welcome to the wonderful world of standards. You know, all those things that people hope to comply with without really trying? If you first understand standards, their design and purpose, you'll see that's really the easiest way to do things. On the web, the trick is simple: you have

• the data layer (HTML)


• the presentation layer (CSS)


• the interaction layer (Javascript)

Now, what standards teach you is that in HTML you should put all your data, and nothing more than that; in your CSS files the presentation layer and nothing more than that; in your Javascript all of your interaction layer and nothing more than that. Remember allways to avoid some mistakes: an anchor belongs to the data layer and not to the interaction layer, so doing stuff like <a href="javascript:"> is just shooting yourself on the foot. Now, if you have this scenario, you have your website (still without AJAX) and you can do all the funny stuff you like to do with Javascript. The good thing about this scenario is that if you disable the Javascript (or if you use a Javascript-less browser) all the blings, bells and whistles disappear, but all the data is there, and presented the way you design it to. Now, if you go one more layer and disable your CSS (or if you're using a web browser without CSS functionalities) you have all your data there (again), just as it should be, only without that stylish presentation you wanted to (which is pretty but useless to someone blind, anyway).

So, the thumb rule is simple: build your app as progressive enhancement, 'cause progressive enhancement automaticly guarantees graceful degradation.

Now, let's add AJAX (or the XHR component of it) into the equation. Most developers agree with all I've said until now: the need of a clear separation between HTML, CSS and Javascript, specially if you're talking about CSS's or DOM scripting. But when we talk about AJAX... they suddenly cast it aside. The problem is, basicly, that you're with the wrong mindset. Instead of thinking that AJAX is just a way to update parts of a page without refreshing, or, in the other hand, you think that AJAX is the spetacular awsome cool new thing that lets you update parts of a page without refreshing, you should look at AJAX as this new way of talking with the server asyncronously and deal with the page accordingly. Leave that "it's not a page, it's an app" thing, the app is what you built, but what you're serving is a page... even if it dynamicly changes itself over time (thanks to AJAX or not).

But I still didn't explain the Hijax part: how to add AJAX to the equation. Well, it's pretty simple indeed: just pick your non-AJAX pages, with links and forms that do requests, and just use JavaScript to intercept those requests and transform them into XHR.

This isn't meant to be an in-depht post about Hijax, more like "why you shouldn't be that excited with AxsJAX" than everything else. Anyway, if you liked the concept, just read Jeremy Keith's "DOM Scripting Blog" [1].

[1] - http://domscripting.com/blog/