Introduction to HIJAX
- Introduction to HIJAX
- The Architecture
- Server-Side Application
- Client-Side AJAX Application
- AJAX or HTML?
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In the Web 2.0 world, every idea or paradigm has to have a catchy name, and HIJAX (which gets lots of its gleam from the –JAX suffix) is no exception. It definitely sounds better than Progressive Enhancement when using Asynchronous JavaScript and XML, which is what HIJAX is all about—giving users without JavaScript access to your AJAX-centric applications.
Introduction to HIJAX
In my previous article, "JavaScript Progressive Enhancement in Practice," I described how you can ensure that all visitors of your web site, including search engine spiders and users on low-end or mobile platforms can get as much functionality from your web site as their browsers allow. HIJAX is an extension of that methodology, making sure that all visitors of your web site get at least the basic functionality your site offers while giving the visitors with JavaScript support all the benefits they expect from a well-designed AJAX application. This might seem like a paradox at first; however, using the right development methodology can get you as close to that goal as you wish. In words of Jeremy Keith, you need to do the following:
- Plan for AJAX from the start.
- Implement AJAX at the end.
In this article, I’ll show you how you can do that in practice using a simple application you’ve already seen in my previous article on the frequently asked questions. While the questions and answers were stored as a simple HTML page in the previous article, now we’ll fetch them on-demand from a relational database.
Before jumping into the implementation details, let me conclude this section with a few words of warning: The more interactive an application is, the more effort (and time and money) you’ll have to put into developing two streams of it (the static HTML one and the AJAX one). Some applications are simply not interesting for the search engines (Gmail is a perfect example) and in some cases you might decide to ignore the small percentage of users who can’t run JavaScript (more so if you’re offering the applications for free). In other cases (such as the FAQ application), you would want the search engines to find all the information, so going the HIJAX route is the only sensible approach.
The majority of the applications fall somewhere in the middle—some parts of them are viable candidates for the HIJAX methodology, whereas the more advanced functions could be made available only to users with JavaScript. In one of my applications (a public repository of rock climbing data), I decided to give read-only access to all data stored in the database to everyone, whereas only users with JavaScript-enabled browsers can modify the data, and the high-end functions are made available only through browsers that support XSLT (which excludes most releases of Opera).