Laith Zraikat

I Innovate, Therefore I Am.

So you've eliminated page refresh!

The hype is still on. "A.J.A.X." Frameworks are being developed to help programmers develop web applications that do not refresh. There's a lot of talk about doing it, but not enough about why it needs to be done. Do we really want to develop such applications on such a wide scale? Are users actually requesting that?

I personally refuse to believe that users dislike the page refresh nature of the internet and are more interested in seeing applications that don’t refresh between requests.

I believe Internet users care more about innovative applications, page loading speed, ease of use, and an error free experience. Whether the page refreshes after clicking a button or not becomes trivial if the application sucks, or if it takes too long to send back a request, or even worse, if you get an error. One could also argue that Internet users are now so used to seeing the page refresh that it doesn’t bother as many of them as it used to.

As a developer I do advocate the use of asynchronous callbacks (or Remote Scripting) when it is absolutely "needed" in "some" parts of your application, and when it improves the user experience without adding unnecessary confusion for the user or the developer.

Due to the disconnected nature web applications, complexities will arise for developers when this problem is amplified in an environment using remote scripting for the following reasons:

  • You can’t easily debug JavaScript. Take it from me, it is a nightmare to develop.
  • You can't log errors that occur on the user side without writing separate routines to send back error details to your server "asynchronously".
  • Special routines have to be written to enable the application to break down gracefully in case of an error without scaring the user while still informing her of the error.
  • Different browser standards for implementing remote scripting.

Finally, take Microsoft for example, they did not use remote scripting in their MSN Web Messenger. It could have used less refreshes, but I guess MS are aware of the complexities involved, and they wanted to keep their application as error free and as compatible with all browsers as possible.

The HYPEx around AJAX

First, let me declare that I really hate meaningless acronyms, I don’t just dislike them. Now what’s the deal with everyone and this new acronym, suddenly there's something called an "AJAX Specialist"?!This is like saying "HTML & GraphicsSpecialist" instead of "Web Designer". Why not just say "JavaScript Developer" or "Remote Scripting developer" –for those who insist on using fancy words- and give all of those JavaScript developers out there a chance. After all, isn’t the bulk of the work in any so called AJAX application done using JavaScript?

Almost every web designer and developer has had some JavaScript experience, and almost everyone with JavaScript experience has done some design and development for the web. The majority have had good experience with both.

AJAX is an abbreviation for: "Asynchronous JavaScript with XML".

  • JavaScript: a very old and great language.
  • Asynchronous: simple put means "without refreshing"
  • XML: It's actually not a requirement, because you can use plain text if you want and it will work just as good.

So we see that the core lies in the word "Asynchronous" –making callbacks to the server without refreshing the page. Asynchronous callbacks are the transport element in a broader concept called "Remote Scripting", which is made possible using JavaScript through the "Microsoft.XMLHTTP" ActiveX Object in IE and the "XMLHttpRequest" object in all other browsers. One interesting fact is that neither Microsoft.XMLHTTP nor XMLHttpRequest is a standard.

After retrieving your data through remote scripting, anything you do next will use methods that manipulate the Document Object Model which has been supported in all browsers for a long time. This data doesn’t even have to be XML formatted, it can be any form of text which suits your needs. XML just happens to make more sense these days.

The really funny part is that a lot of people talk about AJAX as a standard. Let's revise some facts:

  1. Neither Microsoft.XMLHTTP nor XMLHttpRequest is a standard for all browsers.
  2. Your data can be any form of text, not just XML.

So how can a standard be based on things which are not standard themselves?

I think the only good thing that came out of this new acronym is enabling non-techy business people to talk about "Remote Scripting" without having to explain and prove that they know what they're talking about.

I also don't like my janitor to be using the same jargon I use. So to me, AJAX is that very potent dish washing solution or kitchen and bathroom surface cleaner and thats how it stays. for more information about AJAX click here.



<<Home
<<Previous Page[ Page:2/2 ]