heyblog

Requests via XMLHTTPRequest don’t register in the browser’s history, but not all “Ajax” techniques use XMLHTTPRequest. Methods such as JavaScript Remote Scripting use an iframe to grab the data from the server, which seamlessly allows the back button to work if coded properly. A similar technique is used in Google Maps which works beautifully with the back button.

In my opinion, what is described by Jesse James Garrett as “Ajax”, should be referred to as a client-side technique or as an implementation solution rather than “engine”.

XMLHTTPRequest ActiveX object is not the only way to achieve smoother interaction between human user and web-based graphic user interface (GUI). For the past 4 years I’m successfully implementing very similar technique based on HTML iframe. HTTP request targeting HTML iframe is sent to web server and the returned (X)HTML code is nested into existing HTML div object by it’s ID using JavaScript and InnerHTML property. This solution, based on running “secondary” requests to a web server in hidden from operator eyes inner frame, works on IE6 (and on older versions) and may be adapted to other browsers by generic, HTTP-sniffer-based, JavaScript code adjustment.

Three major goals critical for web-based application are achieved by this technique. First, cutting the initial loading time of the screen by providing web-client only with content essential for usable and basically informative screen lookout. Second, managing limited system infrastructure recourses more efficiently by loading any additional content only on operator’s demand, initiated by interaction with the screen: clicking on icon-like image, selecting an option from the list, pressing a button. And last, but not least, providing a system operator with smooth application-like user experience.

While the “Ajax” solution, implemented by ActiveX object or by HTML iframe, is suitable for local intranet solutions, it may be problematic for use in the internet web-sites. Both, HTML iframe and ActiveX object, have earned themselves a very poor reputation due to related security issues, especially on Microsoft platforms. That’s why a careful surfer may disable those in his or her web-browser security settings, if possible (like in most commonly used IE6). In case of corporation using IE6 the employees may be instructed to add the application IP address to the “Local intranet” web content zone with custom, less restrictive, security settings. Such policy may not be applied on the general public of internet surfers.

Contemporary web browsers are developed and security settings are configured with common internet surfing in mind. Simultaneously, the growing demand for a web-based interface from the corporate policy makers forces web developers to implement “application mock-up” techniques, like “Ajax”. May be in the future there is going to be an accepted standard for online applications and a compliant browsers with embedded client side “secondary request engine”. But even then, mostly due to accessibility issues, this solution will remain corporate-intranet oriented and not suitable for the internet web sites.