The internet world is moving towards a rich and fast user experience at a very rapid speed. AJAX is contributing majorly in this direction.
AJAX [Asynchronous Javascript And XML] is not a technology, it is a concept built on the existing technology provided by major webbrowsers.
The native XMLHttpRequest object or the Microsoft.XMLHTTP ActiveXObject enables the use of AJAX. Using one of these [as the case may be] objects, the javascript code in a webpage can asynchronously send the HTTP's GET/POST request to a webserver. Javascript can be further used to display the responseText/responseXML anywhere on the existing webpage. This way some text [or image or any other HTML object for that matter] can be changed on the existing webpage without reloading the whole page.
Gmail, Orkut, Google Suggest and many other existing and upcoming sites use this concept extensively.
You can find a detailed explanation and examples of how to implement AJAX in your applications here.
AJAX requires the response from the webserver to be in XML format. To further improve the performance of the application, XML can be replaced by something light in weight. JSON (JavaScript Object Notation) provides a fat free notation of JavaScript objects. AJAJ (Asynchronous Javascript And JSON) does exactly this. By the use of AJAJ you may not have to fetch/parse the responseXML of the HTTP object to extrace the relevant info. The responseText can be directly loaded in the JavaScript variables. The official JSON website demonstrates this with beautiful examples.
There are 2 benifits of using AJAJ over AJAX:
1. JSON is lighter that XML.
2. You do not have to parse JSON on the client side to initialize JS variables, unlike XML.
Going a step further, we may even replace the JSON of AJAJ with JavaScript. I call it AJAJS [Asynchronous JavaScript And JavaScript]. Insead of responding with the responseXML or a JSON in the responseText, the server might respond with a javascript code in the responseText. And on the client side, you may use the JavaScript eval() function to execute the responseText. So now the responseText can even be a function call.
Eq:
suppose http.responseText = "showMessage('From: chhabra.kapil@naukri.com', 'Subject: Hey!', 'Body: How do you do, buddy! ...')";
Now suppose that showMessage is a function in your javascript that accepts 3 parameters to display an email mesage on the page, you may just
eval(http.responseText)
in your client side JS code.
Becoming a Freelancer as a Finance Professional
5 years ago
Posts
8 comments:
AJAJS surely does look really good. Very nice. I feel using AJAJ and AJAJS in parallel will happen for ppl who value speed. AJAJ may be used when we have a lot of data to get but AJAJS will be the best for just getting a command with a few parameters. Also AJAJS may require knowing the functions available in the client side js. This may be a limiting factor in some cases I feel. Since my understanding is not as deep as yours, I think you can throw some light on this. Say what? :)
Its true that AJAJS will require knowing the functions in the client side JS; and I somehow feel that its a pro rather than a con. You send something from your web server, that only your functions can understand and it remains a garbage for the rest of the the world.
Although, AJAJS can be used to get a lot of data as well, I would rather use AJAJ. But its always good to avoid sending a lot of data through one request. UI needs to be extremely intuitive in case a lot of data is being transmitted, as it may take a lot of time as well.
Rightly said I guess. My concern was around mixing of model and view and the maintenance impact it can have. But on the second thought a good design can take care of it.
Another thought is this that there can be a general AJAS (Asynchronous Javascript And Script), building upon your idea ie why only javascript, such calls may be generally returned for an script being used on the client side. I may use it in, say flex, to trigger AS3.0 functions. Can be useful. It is a nice thought Kapil that you have come up with. cheers!
I use AJAJ and the calls return an Array with the HTML code to inner and the JavaScript code to execute.
The JavaScrit retourned can operate with HTML code retourned too.
Way back in the ancient days before XMLHttpRequest, we did AJAH and RIA without even having acronyms for it, by frequently (re)loading a simple HTML page within a hidden frame. This data page consisted merely of a header with JavaScript arrays and an automatically executed method to inject this data into the surrounding HTML UI, depending on its current context. Worked great and even has a bunch of benefits over XMLHttpRequest: supported 1:1 by literally *any* frameset and scripting capable browser, no evil eval(), effortless browser intrinsic and UI tolerant handling of errors like 404's, if server is (temporary) unreachable, the option to proactively bind additional JavaScript functionality to the data page, initiated on server side, and so forth.
Last but not least, the whole process is easy to handle, to follow/log, and much easier to debug - 10 years ago, Firebug & Co. were tools one could only dream of... Sending payload to the server BTW was attached to the cyclic GET/POST requests that fetched the data page.
Actually, I don't know why we all do XMLHttpRequest based AJAX/AJAJ today and dropped the approach described above… Are there really advantages in doing so? Or is it just chic?!?
Dear Phillippi
RIA has expanded beyond making asynchronous requests. Besides the usual problems associated with frames (http://www.evolt.org/article/evolt/22/293/) , frames are not capable of micro-updates (updating only a row of a table without refreshing the page, for example). They are also not able to respond to user inputs in real-time (can you imagine making Google Wave with only frames?) which makes it difficult to make responsive applications. This has been made possible by faster internet speeds, better javascript engines and improved hardware. So, it is definitely not chic and it is the way to future interfaces.
I think you don't get what I was trying to say: we were using 1 visible frame for the UI and 1 completely *invisible* frame just for data transport. I don't want those antiquated 1000 frame GUIs back (Jesus, no!), I just described the replacement of an invisible client/server data transport technique that does not interfere and has nothing to do at all with GUI aspects like responsiveness, (pseudo) real-time interaction etc..
This 10 year old frame based data transport is as fast and powerfull as XMLHttpRequest is, the HTML overhead is minimal. Therefore, I could realize literally EVERY modern browser application 1:1 using this approach and without XMLHttpRequest, let it be Google Wave or Google Docs or any other top notch Web 2.0 stuff. Maybe I could do it even better with this!
The only aspect I see different is security, though. Frames have always been a security hole and it's certainly easier to cheat a frame based technolgy like XMLHttpRequest object requests. The browser vendors have learned their lessons, I guess.
Dear Phillipi
I see your point. In fact, I remember some friends using IFrames for a similar purpose. Nevertheless, security is an issue (though XMLHttpRequest comes with its own baggage). Extensive use of Javascript based frameworks like Ext and YUI also favors AJAX. The developer would find it pretty convenient to use inbuilt AJAX libraries than using frames here because it would help in populating the UI components faster (unless all components are re-written to read from a frame). Also, discrete and on-demand data fetching may be a bit more complex with frames. Further, RIA includes non-html frameworks like Flex (which are Flash-based) and have their own way of making asynchronous requests.
Post a Comment