Let's not give it any more credit than that.
I think we should. Here is a simple scenario, you have a web based software. Lets call it "courier/shipping software" , courier company has 100 customers and customers shipping pkgs. So they have to invoice them periodically. Say each customer ships 100 pkgs p/w. Its monday and we gonna charge all those shipments, prepare invoice for them and send them invoice + notifications.
Without XMLHttpRequest:
Load the list of customers who would be charged today to a web page with basic info (shipment count, total amount, surcharge amount etc...)
Now we can not load all this info on a single page (for 10000 records. 100 customers x 100 shipment) and operate on them unless we play around with script memory limit, script time limit, max body etc... (even than it is pretty hard)
We can spit it to 10 customer per page so we'll have to load 10 pages to operate on 100 customers.
Now we are on 1st page with 10 customers loaded we selected 6 of them and click on calculate button (we have to review numbers before we actually charge them)
so we are dealing with 600 record at this point ( 100 pkg x 6 customers ) say each shipment takes 0.5 second to be calculated (calculate dims, vol weight, find zone, find rates, apply them etc...)
Once we click on calculate button we have to wait 300 sec ( 100 pkg x 6 customers x 0.5 sec) . Of course we can not expect accounting person to wait 300 secs just to calculate charges for 6 customers.
So we decide to use dom and iframe. We'll split the load to chunks and give interactive impression to the person who is using our app. Once he clicks calculate we'll send 1st customer accnum to iframe (with Dom) call our script and our server side script will do the calculation and show results. Once server side script finished loading we'll call parent window to send the next number and repeat the process. (without Dom we are completely screwed)
At this point we lost all info (visually) related to previous results (There are workarounds but thats not the focus).
Also don't forget user will still be looking to a empty iframe for (0.5 per shipment x 1 customer x 100 shipments = 50 seconds)
I wont continue with rest of the process but just to mention i didn't go into traffic load (you have to load same page over and over) and processor load (you have to render same script over and over) and other factors to keep this post brief.
(Also before anyone throws you are a bad coder a calculation can not take 0.5 sec argument change it to 0.1 or 0.01 if it makes you happy. But it wont change the fact)
With XMLHttpRequest:
Load the list of customers who would be charged today to a web page with basic info (shipment count, total amount, surcharge amount etc...)
We load 20 of them if needed user can click on "load more" or "next" button to get rest of the list (we are still on same page)
We select 20 of them and click on calculate button. As soon as we click on calculate we start to see results:
Shipment 1: 10$ transportation charge 2$ fuel charge Zone 1 etc.....
So while we are waiting we are seeing almost real time results. (No more time outs, traffic load etc....)
Also during this time we are doing other things with our software within another DIV on same page while we are keeping eye on results.
And don't forget we can select all 100 of customers and do calculation at once we don't have to go 6 or 10 customer per click.
(Which is practically almost impossible without XMLHttpRequest)
And more importantly:
Other than technical advantages (bandwidth, processing etc...) XMLHttpRequest give users the impression as they were using a desktop application.
After XMLHttpRequest companies started to look at web as software platform and started delivering their products as web based instead of desktop/compiled based.
And If you dont know anything else just know this if you are able to use QuickBooks online or Office suite online thats because of XMLHttpRequest
So yes, XMLHttpRequest deserves a lot of credit.