But as the writing of the book progressed, Ajax really began to explode. It became clear that I’d have to at least mention the subject, even if I couldn’t cover it in detail. That’s where the book’s final chapter came from.
I felt it was important to hammer home a point I had been trying to make throughout the book, namely that progressive enhancement automatically guarantees graceful degradation. I was concerned that developers who agreed with this principle when it came to CSS or DOM Scripting, cast it aside as soon as Ajax was involved.
“It’s a whole different ball game”, cried the excited developers. “See, these aren’t web pages, it’s a web application.”
But most applications, web-based or not, still work on a document basis. Think Word, email, even Photoshop. You’re still manipulating a file. What Ajax brings to the table is the ability to manipulate a file on the Web without constantly refreshing the whole thing.
Web applications and web pages are not mutually exclusive. One is built on top of the other. Far too often, the builders of web applications concentrate on the “application” part to the detriment of the “web” part.
There are many definitions of the Ajax methodology floating around, but mine is very basic indeed:
The ability to update part of a page instead of the whole page
(and, yes, I do realise that, by that definition, framesets and Flash fall under the Ajax umbrella.)
Now, depending on how your mind works, you could apply that definition in one of two ways. You could say:
“What’s the big deal? Ajax is just the ability to update part of a page instead of the whole page.”
Or you could say:
“OMG! With Ajax, you can update part of the page instead of the whole page!”
Both viewpoints are valid. The value of Ajax lies in-between. It lies in the ability to appreciate the power that comes with being able to make asynchronous requests to the server without a page refresh, while at the same time always bearing in mind that you are still dealing with documents.
If that’s your mindset, then building Ajax applications that degrade gracefully becomes a no-brainer. I wrote some time back about progressive enhancement with Ajax. It’s a very simple idea:
- First, build an old-fashioned website that uses hyperlinks and forms to pass information to the server. The server returns whole new pages with each request.
XMLHttpRequestinstead. You can then select which parts of the page need to be updated instead of updating the whole page.
I’ve even got a nice shiny buzzword for this technique: Hijax.
Of course, it’s not quite as simple as all that. You need to make sure that your server-side architecture is quite modular: capable of returning entire pages or portions of pages (hint: APIs are cool.)
There seems to be an inherent paradox in saying that you need to think about your server-side architecture but you should just be building old-fashioned page by page submissions before hijacking them with Ajax. But the paradox can be resolved if you think about Hijax this way:
- Plan for Ajax from the start.
- Implement Ajax at the end.
If you build your Ajax apps like that, you can have a Web 2.0 app and a Web 1.0 website, as recently tested by Chad Dickerson. He ran two Ajax apps (Gmail and Backpackit) through Lynx, the text-based browser. Gmail fails miserably, Backpackit works just fine.
You can try the same test on my own little Ajax/Hijax app, Adactio Elsewhere. Run it through Lynx, run it through a mobile browser; all the functionality is still there just without the partial-page benefits of Ajax.
Thomas Vander Wal sums up the situation with Ajax apps nicely:
“But, it must degrade well. It must still be accessible. It must be usable. If not, it is a cool useless piece of rubbish for some or many people.”
If you’re serious about using Ajax in a way that degrades gracefully, think Hijax. If you want hands-on, in-depth instruction on Ajax, Hijax, progressive enhancement and graceful degradation, come along to my Ajax workshop in London on February 10th.
Posted by Jeremy on Sunday, January 1st, 2006 at 7:40pm