The XmlHTTPRequest function was designed so that the client can get small pieces of information from the server without having to do a page refresh. Obviously, the developers thought that XML will be the format of choice for this data exchange.
Thank God they didn’t make XML validation necessary!
I say this because XML will not be the format of choice for this data exchange. Let’s see why.
Firstly, let’s see how the data flow will be in the case of XML over XmlHTTPRequest. A typical scenario is where the data lies in a database on the server, and the data is requested by the client. The steps in the process will be:
- Server reads the request, extracts the data from the database.
- Server prepares an XML document using this data.
- This XML is sent to the client.
- Client validates the XML for well-formed-ness.
- Client extracts data from the XML markup.
- Client calls functions/triggers events which use this data as parameters in some way or other.
- Is it necessary to prepare an XML document (step 2 above)? Isn’t that an extra step that is probably not necessary?
- Client validation is necessary (step 4 above) to ensure that the XML parser can parse the XML. This puts heavy processing requirements on the client. Is this really necessary?
- The data from the XML will then have to be extracted (step 5 above). This isn’t really a necessary step either if the data is not marked up as XML. So, then, is it really necessary to use XML?
So, in what format will data be transferred over XmlHTTPRequest? The simplest way is as a plain old string of data. This will be the most efficient as far as download speeds are concerned. You will download only 11 bytes where 11 bytes of download is required, not more. Besides, there won’t be any XML parsing or validation in the picture, making the application that much faster.
However, somehow, I don’t see data flowing over XmlHTTPRequest in the form of plain strings of data either. Instead, I think it’ll flow in the form of JavaScript code.
Let me use an example from the guy who deconstructed Google Suggest, and the way XmlHTTPRequest works there. According to him, the code returned by Google when you hit a keystroke looks like this.
sendRPCDone(frameElement, "fast bug", new Array("fast bug track", "fast bugs", "fast bug", "fast bugtrack"), new Array("793,000 results", "2,040,000 results", "6,000,000 results", "7,910 results"), new Array(""));
Basically, what this code does is call a function, with a bunch of parameters. The function called,
sendRPCDone, is defined in client side JavaScript code. The parameters are generated depending on server side processing (probably from Google’s cached searches). Then, later in the code, this response text is run through an eval function to execute the function on the client side (eval(_xmlHttp.responseText);).
I think the eval function is really a boon here. It makes JavaScript as the language of choice over XML for XmlHTTPRequest. For who don’t know what eval does, it basically takes a piece of string, treats it as though it is JavaScript code, and executes it. The string could be dynamically generated by client-side code, or as in this case, returned from the server. Just what we need here!
To summarize, here’s why we’ll use JavaScript instead of XML when using XmlHTTPRequest.
- Downloading XML data will take more time as compared to JavaScript. Depending on the amount of data to be transferred, this difference might be huge.
- Use of XML will necessitate validation of the markup, so that a parser can read the document – a process that requires extra processing on the client-side. This is not necessary with JavaScript.
- The XML data is not already in a position to call scripts. Client side code will have to handle that, based on event handlers or such. JavaScript, on the other hand will be ready to be executed on the client.
Did someone say that JavaScript will be coming out of the closet this year?
Previously:
14 comments:
Wow, Adam. That piece of code is poetry!
I was just thinking the other day about dynamically including JavaScript files, and XmlHTTPRequest wasn't the solution to it (or was too clumsy at best).
Your code, on the other hand, is just what I was looking for. Awesome work!
>>It should work with any W3C-DOM browser.
-not Safari. Not old Opera either. Maybe newest, forget offhand. I've used it for ages to send items to the shopping cart when ordering and works pretty well. (Btw, your code needs a timestamp added so not cached by IE. Also IE Mac needs a different routine; you'll crash it with that code.)
>>(eval() is JavaScripts most performance deficient function).
-why not just send the data string and and call the function with it? No eval needed.
>> why not just send the data string and and call the function with it? No eval needed.
How would that work? Let's take the code in question in my post. The server returns the string which is basically that sendRPCDone function call. When that is received by the client as a result of the XmlHTTPRequest response, it'll be for all practical purposes just a piece of string. How do you get it to be treated as a piece of client-side code and execute it, without using eval?
Am I missing something?
Whether this is new or not doesn't really matter. Fact is, it is very underutilized. Which seems to be the case for various reasons:
1) noone seems to be able to come up with something that has decent cross-browser support.
2) the odd assumption that payloads will be XML
3) the apparent cross-domain restriction of hmlhttprequest
Can someone just put together some code that's reasonably cross platform that can do simple POSTs or GETs, ideally to any domain?
>>am i missing something
Yes, don't send the function name from the server, just the string and then send that to the function:
clientsideRPCFunction(serverResponseString);
Or you can set the callback function beforehand if sending an ID back and forth, or send the function name itself back and forth as the first argument, but that involves more coding obviously.
Interesting technique, Anonymous. (I wish you'd leave your name, but really that is Blogger's fault - I understand.)
The next obvious question would be, is it better to eval a string, or better to parse a string and decide what client-side function to call? Which one is more efficient? Which one is faster? Which one would reduce memory leaks (which is increasingly becoming an issue with JS web apps)?
I'd think that for small scripts that essentially have very few callbacks, your technique would reign supreme. However for larger scripts with more callbacks, parsing the response string to determine the operation would be just as performance intensive as using eval, what with complex if-else ladders.
Of course, that's off the top. I have not tested it, nor could I come across anyone who has. Can anyone shed some light on this matter?
The idea of outputting lots of javascript directly from server side code is a bit of a false economy due to changes in javascript requiring rebuilding solutions. Combining with XSLT on the server side can give the flexibility to change without having to rebuild solutions, And also means you can output HTML directly.
You may be get some information about XMLHttpRequest at the http://mcoder.atspace.org
Just want to say, most helpful article for me. I've been struggling to get decent performance for a week, bashing my XML-reading code this way and that. Switching to eval was a perfect solution for getting thousands of records into my Javascript in a tolerable timeframe. Magic.
but what if javascript is off?
William,
This post assumes that JavaScript is available, which is around 96% of the typical Internet audience.
In case you are concerned about cases where users do not have JavaScript enabled, you should find out more about "Unobtrusive JavaScript" and "Graceful Degradation" techniques. It is a little harder, but not impossible, to cater to users that don't have JavaScript enabled.
Anonymous, did you find a way to use your method in a synchronous way?
Regards wizardnet
How will this handle the data which has image also in it?
Why you hack my account,what is the reason
Post a Comment