HomeAjax: It’s not all about XMLHTTPRequest (part I)
In the current craze around Ajax, XMLHttpRequest is getting all the attention. While there’s no doubt it is well deserved, there are other technologies in the Ajax realm that should not be overlooked and XSLT is one of them.
In the Form Builder, there is only one call to XMLHttpRequest, when you click the ’save’ button. Everything else relies on the transformation by the browser (ie. client-side) of XML data using XSL templates. Client-side XSLT dramatically reduces the need for server access. That’s its strength.
The Problem with XmlHttpRequest
In a typical web application the data is modified on the client. A back and forth with the server is used to
- save the data,
- retrieve the new state of the interface, which often involves also,
- reload the data.
XmlHttpRequest makes the round-trip to the server seamless, which can be good… or bad, if you have a noticeable network delay.
In the traditional click & load model, users expect their browser to behave in a certain way when they click on a link or a button. The throbber (your browser loading indicator) should start its animation, the mouse pointers should show the hourglass and the page should go blank before reappearing.
None of those happen when you use XmlHttpRequest, leaving the user with a feeling of uncertainty; ‘did I click or not ?’. To circumvent this, developers need to add a custom loading indicator (welcome to the world of Flash developers…).
What happens really is that XmlHttpRequest is not used for what it is good at: asynchronous, behind-the-scene, access to the server, but in the context of a synchronous transaction by the user.
Users want instant feedback from an application, and a better way to achieve that is by freeing the application from its over-reliance on the server.
When applications break free
To curb down server access, you need to transfer to the client responsibility for two things: (1) maintaining the state of the data and (2) drawing the different screens of the interface. The server remains in charge of saving the finalized form of the data, which can be done behind the scene with XmlHttpRequest.
This is how you can design rich web applications. This is how the form builder is made and this is the subject of the second part of this article.
May 28th, 2005 at 2:40 am
“None of those happen when you use XmlHttpRequest, leaving the user with a feeling of uncertainty; ‘did I click or not ?’.”
Many of the demos I’ve seen so far get this wrong. Worse still is if the response takes too long, they think it’s failed, start clicking on other things and suddenly the response turns up.
To help prevent this, one thing I added to JPSpan was a timeout, which I documented a little here. If the response doesn’t occur within an acceptable timeframe (defaults to a long 20 seconds), an exception is raised which, by default, triggers an alert, although could be handled by the application developer, eg. resending the request.
Some form of indication to the user is also necessary and combined with the timeout, could give a clear indication of a request that’s failed or taken too long.
June 1st, 2005 at 3:42 am
I usually use xmlhttprequest.abort() as a precautionary mesure before making a new request. That takes care of the impatient user clicking several times. The time out handler is a good solution for ‘behind-the-scene’ operation tough.
June 2nd, 2005 at 3:12 am
[…] from Marco Tabini in the anatomy of an AJAX framework. Yet more good stuff to be found in Ajax: It’s not all about XMLHTTPRequest (part I) and part 2. Not Invented Here […]
June 3rd, 2005 at 3:11 pm
[…] eract with directly with AJAX. There is another way to go with AJAX, which is suggested in Ajax: It’s not all about XMLHTTPRequest (part I) and part 2 - namely start trea […]
June 4th, 2005 at 1:39 am
“A” is for Asynchronous - Think AJAX, Think Modeless
Today’s entry is brought to you by the letter “A”. **The “A” in AJAX stands for Asynchronous**, and Cédric Savarese cautions that many AJAX applications treat XMLHttpRequests synchronously. That is, they submit data and do something when it resp…
June 15th, 2005 at 5:25 pm
Well I learnt at college about UI design and how you’re supposed to design your UI around the end-user assuming he’s as dumb as a dodo. This brings us to the aspect of UI control too. I just did an application which emulates the AJAX framework through the use of iframes (yeah! I wasn’t comfortable using it just yet)
1. I gave the application back-end a status bar that looks just like the browser’s status bar. All application status messages appear here. However I failed to take into consideration the timeout factor.
2. After the user clicks the button on the form, the button gets disabled, and a the status bar tells them to wait while the data loads. Now on dial-up this wait time was at most 10 seconds, with the client who uses a 5 Mbps conn, it was like using a console app.
The point here being, all of the “bad” points mentioned about AJAX arise out of bad practice. J.J.Garret in his article where he coins the term AJAX for this tech mentions clearly about these aspects of application design with this technology.
The idea is not just to use it and find the flaws, but to use it right and then try to pick out faults.
February 15th, 2006 at 4:11 pm
[…] As Bill called it Client / SOA will use the same. SOA may not yet be concept which readily communicates ideas. My angle of understanding this begins with asking AJAX: what’s a session?. An alternative angle comes from Cédric Savarese over at Form Assembly in Ajax: It’s not all about XMLHTTPRequest (and part 2), a train of thought which leads to what he’s done with the freja framework. […]
February 17th, 2006 at 12:43 am
[…] As Bill called it Client / SOA will use the same. SOA may not yet be concept which readily communicates ideas. My angle of understanding this begins with asking AJAX: what’s a session?. An alternative angle comes from Cédric Savarese over at Form Assembly in Ajax: It’s not all about XMLHTTPRequest (and part 2), a train of thought which leads to what he’s done with the freja framework. […]
November 25th, 2006 at 2:57 pm
[…] Ajax: It’s not all about XMLHTTPRequest (part I) - “…there are other technologies in the Ajax realm that should not be overlooked and XSLT is one of them.” […]