When I was originally writing the DOM Scripting book, its scope was very clear - it was to be an introductory work on JavaScript and the Document Object Model, with an emphasis on best practices. I made a conscious decision not to cover advanced topics like XMLHttpRequest.
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.
- Now, use JavaScript to intercept those links and form submissions and pass the information via
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
Comments
Hijax….I like it. Nevermind the fact that it took me several months to come around to finally being comfortable with saying "Ajax". I too am guilty of just calling something ajax even when it’s not entirely that. It definitely has become that umbrella you talk about thus coming off more like an idea and concept.
When you do this - it’s ajax. When you do that - it’s ajax. Hey, let’s use Ajax! Yea…
Another aspect of AJAX degradation that many seem to miss is that of search engines and other web crawlers. Most of these don’t speak Javascript—and thus AJAX is way beyond them. Search engines will not be able to fully crawl a site that is 100% AJAX unless it degrades gracefully.
# Posted by Scott Johnson on Monday, January 2nd, 2006 at 11:21pm
Yeah, and that’s not just a problem with AJAX. Those "javascript:" and "#" hrefs are still around on a lot of sites that do old school dynamic dropdown/flyout menus. I’ve been guilty of that in the past, though I know better now.
# Posted by Dougal Campbell on Thursday, January 5th, 2006 at 4:47pm
Jeremy, what is an alternative for using href="#" or href="javascript:" links? Are you saying about using a meaningful links lwith href="somerealURL" and having onclick event handler which stops this link from being followed and executing some [Ajax] JavaScript instead? Could you explain? I like your idea of "progressive enhancement and graceful degradation" using a modular server-side architecture "capable of returning entire pages or portions of pages"! It’s clear and doable! Basically, you need to write a set of functions or maybe a class with set of functions running on a server and then have one page [with server side script and no html] which handles a normal form post using a set of those functions, and other pages which handle xmlhttp request post/get submissions by using an appropriate subset of the same functions. It could be even the same page which behaves differently depending on who and how calls it. A kind of Web Service :) This page then either redirects to an appropriate HTML page, or just sends an appropriate XML or text back to AJAX caller.
http://pro-thoughts.blogspot.com/
# Posted by Vladimir Kelman on Sunday, January 8th, 2006 at 5:44am
Hijax…… Dumb buzz word. Good concept.
# Posted by James on Wednesday, January 18th, 2006 at 11:54pm
I dunno, I like the buzzword - requisite amount of pun and injoke detected.
An aside though, with the way that the ‘standards’ minded developer works is ‘degrading gracefully’ correct? Cart before the horse, perhaps, as the way that I’ve seen it described by the standards minded they’re more geared towards ‘upgrading usefully’.
I followed this Progressive Enhancement/Graceful Degradation idea and extended it with some object oriented approach to behaviour separation.
You can see the idea there: http://6v8.gamboni.org/ObjectiveDegradation/hcal.html
and explanation here: http://6v8.gamboni.org/ObjectiveDegradation-Javascript.html
It’s a prototype now. But I hope you guys like it.
# Posted by Mortimer on Wednesday, January 25th, 2006 at 6:32pm
Nice idea, I like it a lot, but your example doesn’t really do what you have described. It degrades nicely but it doesn’t show how the server side can help this. I.e. the whole information is dowloaded at once an then if we have JS enabled then some parts of the page is hidden, if we don’t then it’s just a simple page. But no demo of partial and full page downloads from the same webapp. This way it’s not AJAX but only ‘DHTML’ (if we can use this world nowadays ;) ).
For this demo to be AJAX it would have to be rewritten so that it did HTTP requests to fetch some part of the page as the user clicks the header bar.
# Posted by atleta on Thursday, January 26th, 2006 at 2:18am
And another comment on this. Doing a webapp the hijax :) way also has the advantage that you can jump into the middle of it using a direct URL. (Though you would have to be tricky to get the URL. I don’t really know much about JS in web pages, maybe it can replace the text in the URL location bar.) You can also use the standard browser functions such as the ‘Open link in new tab/window’ from the right click menu. Something which can be very irritating to miss if the designer chooses to use java script for handling links.
# Posted by atleta on Thursday, January 26th, 2006 at 2:25am
atleta, yes, right now there is no server-side code to support the thing, I was too lazy to create a DB etc for the thing ;)
I was hopping that people would get the principle and see how it easily extend to you progressive-enhancement technique.
As there seems to be some interest on the technique, I am currently writting the tutorial on multiple inheritance that will introduce AJAX query and use your progressice enhancement method. But it requires more development on the server-side as the code has to be really modular. Should come soon ;)
# Posted by Mortimer on Thursday, January 26th, 2006 at 11:06am
Personally I think you should always think about how users are going to get to different parts of your app if it’s in AJAX. As with Flash, there are no bookmark points in a totally AJAX site. Therefore unless you are going to maintain a server and client side version of the app, it’s best to use AJAX not as the central delivery mechanism for you content but as an enhancement. That being the goal, I question the necessity to completely replicate such an app with a server-side version. Since you shouldn’t be using AJAX to deliver the "meat" of the page, anyway, there shouldn’t be a need to develop a parallel web 1.0 version.
# Posted by Steve Krutzler on Friday, January 27th, 2006 at 4:51pm
I’ve been pushing this idea for almost 6 years (before it’s time?) http://www.halfbakery.com/idea/dom_20browsing
Which inspired this: http://devedge-temp.mozilla.org/viewsource/2003/inner-browsing/index_en.html
So I’d be excited if this idea got more traction. Another thought - imagine if you also inverted the idea meaning imagine if you had the data on a page in some raw format, and you could reference a "template" which was the real html (empty of content but with id’s for the ‘buckets’). You then refer to that template in your page which get’s cached as its own ‘entity’ in the browser cache and could be used over and over for multiple sites. Templates could be created using some standard for describing ‘content’ ‘menus’ etc. You could even have the user specify the template on their own side which could make for seriously fast browsing. Just my 2cents.
# Posted by Andrew Wooldridge on Friday, January 27th, 2006 at 6:15pm
Sorry. Comments are closed.