When to use XMLHttpRequest and when to use IFrame
by Kevin Dangoor
Joel Webber dissects maps.google.com in Mapping Google. He spent a good deal of time getting into what all is being done by Google Maps. Here’s an interesting takeaway:
I mentioned before that there was some advantage to be had by using a hidden IFrame over making direct XMLHttp requests. One of these is that the IFrame’s state affects the back button. So every time you do a search, it creates a new history entry. This creates an excellent user experience, because pressing the back button always takes you back to the last major action you performed (and the forward button works just as well).
This leads to a good rule of thumb. If you’re updating the page with new or updated information, you most likely don’t want a history event. So, use XMLHttpRequest. On the other hand, if you’re working in resposne to a user request, it would often be better to use the IFrame approach in order to preserve back button behavior.
This is a very useful guideline, thanks!
Is, there any way by which same functionality of back button can be achieved by using XMLHTTP, by writing more javascript inside?
Also, how is GMail doing it?
as mentioned in this article
http://jgwebber.blogspot.com/2005/02/mapping-google.html
GMail is using XMLHTTP and still able to do the back functionality properly.
How is that happening?
I’ve actually had trouble with using the back button with GMail. I’ve generally used their navigation options (which have been fine).
It’s worth noting that the “profile build” of the DojoToolkit offers a powerful mechanism for doing client/server communication, including back/forward support.
My webmaster technology watchlist for 2005
The savvy webmaster wants to keep a close eye on those savory technologies for future use in production sites: lighttpd…
What is you’re running XHTML Strict with the correct mimetype on browsers that support it and XHTML hiding behind XML on IE? You can’t use iframes in that case. What would your recommendation be there?
Oops, I meant “if”. ^_^;
Take a look at Dojo http://dojotoolkit.org. They (and others out there) are experimenting with doing history munging and stuff to get the back/forward buttons working as expected. I don’t know if there’s any reason dojo wouldn’t work with XHTML pages.
I don’t know, but dojo seems to be quite big.
XHTML with the proper mimetype will not allow iframes and certain scripts, so that’s what you have to watch out for if you’re doing strict XHTML.
I tried dojo with XHTML and the correct mimetype and it didn’t work. document.write doesn’t work with the XHTML mimetype. S, I’ll have to figure out my own method, I guess.
“This leads to a good rule of thumb. If you’re updating the page with new or updated information, you most likely don’t want a history event. So, use XMLHttpRequest. On the other hand, if you’re working in resposne to a user request, it would often be better to use the IFrame approach in order to preserve back button behavior.”
This makes no sense to me. If I am updating the page with new or updated information, odds are really good that I am doing so in response to a user request. So where does that leave me in terms of this advice?
For what it’s worth – in the tinkering I am doing lately, I have a screen with info from a database, which allows the user to edit the info, and submit it. I’m using an iframe to avoid refreshing the page every time, and it seems to operate reasonably. If the user its the back button, rather than getting the previous version of the page, the user goes back to the previous screen (in this case, a search page). They can update & submit the record as many times as they want – but the back button will always take them to the search page. That seems reasonable to me. Does it seem reasonable to anyone else?
Cheers!
-sw
http://www.scootertrip.com