Tuesday, February 28th, 2006

XMLHttpRequest Vs. iFrames

Category: Ajax

On Sys-Con.com, there’s a short little look at two methods of doing a lot of the same things – a comparison of Ajax versus iFrames.

Should you use the old iFrame tricks or the new XMLHttpRequest? There is not better or worse when comparing these two techniques, but they are certainly different. While both of them allow you to communicate with the server in the background, you should choose the appropriate for your situation depending on a few questions: Do you want the back-forward buttons to work? Do you plan to perform more than one simultaneous request? Do you need cross-site calls? Do you need to monitor the status of your calls?

He answers these questions, most of them right away with a table listing of the differences between the two (“multithreaded”, “cross-site”, etc). These are followed by arguments for both sides, spotlighting things like:

  • that iframes are easier to monitor, but won’t let you multi-thread
  • Ajax tends to break the back button, but it’s also easier to understand what’s happening with it (via the status codes).
  • neither supports anything that would allow cross-site scripting (for Ajax, a restriction. for iframes, the lack of control between parent/child)

Posted by Chris Cornutt at 2:16 pm

3.7 rating from 104 votes


Comments feed TrackBack URI

well, actually nothing I didn’t already know, but a real useful and comprehensive description of the differences for those who are not yet as adept with the backgrounds ;)

Comment by CountZero — February 28, 2006

Another fundamental difference is that XMLHttpRequest requires ActiveX to be enabled in Internet Explorer. This is a blocker for using XHR in many large deployments, especially b2b applications, where ActiveX is disabled for security reasons.
Of course, all of these differences can be papered over by a robust AJAX RIA framework, which automatically selects the best AJAX ‘transport’.

Comment by Jeff Dill — February 28, 2006

it’s easy,but very useful!!:)

Comment by ahappylion — March 1, 2006

I would have liked to see him address the third and much preferred (by me at least) method which is dynamic script inclusion. Simply adding a script object to the document is multithreaded and cross-site capable.

What’s the big deal about status? The only time I have needed any intermediate state other than “I’m done” is when a request takes a long time and the Iframe method is actually much more poweful in that case becaue it can use progressive rendering of html.

The back button is another headache altogether and is not really dependent on whether you use iframes or xmlhttprequest. If you want it to work your best bet is to implement a framework around it like the rsh object by Brad Neuberg or the related Hashlistener from Erik Arvidsen.

Comment by Atli Thorbjornsson — March 1, 2006

Indeed, Atli. DOM script injection is (IMHO), the better of all 3 approaches.

1. It requires no ActiveX
2. It’s much faster than the XMLHTTPRequest object (I’ve used both, done the tests). This is in regard to the actual construction of the object, and with regard to evaluating scripts (no clunky meniacal eval() calls).
3. Much smaller memory footprint.
4. Cross-site compatible.

Comment by Ryan Gahl — March 1, 2006

I use XmlHttpRequest and feed response output to an iframe.

Comment by Shy Guy — March 2, 2006

[…] Compare, XHR v iFrame […]

Pingback by diatribe » Blog Archive » Of Interest v20060304.1 — March 4, 2006

What’s the big deal about status? The only time I have needed any intermediate state other than “I’m done” is when a request takes a long time and the Iframe method is actually much more poweful in that case becaue it can use progressive rendering of html.

Comment by online backgammon — June 15, 2006

Good! give user more experience.

Comment by Matching — September 5, 2007

Ajax has one weakness witch i find a great one, and i think that people working with it should consider it much more than they do t now…
Its problem with character encodings.
When you use Ajax call it does not render special charachter encodings other than utf-8.
Also when im borwsing some sites in spanish or some scandinavian languages ive noticed that browser does not render correctly some special characters …(because i have set my browes to read char encodings form where im from)
Man that lets you with a bad test in your mouth..So we might say that A… sucks
Big idea(l)s often falls on small things!
…and we out!

Comment by mario — November 1, 2007

I think either DOM injection or iframes will do the job. At least as far as the bandwidth and server horse power won’t let a ajax page refresh or evolve to let say show, for example, an animation where the info to be drawn homogeneously may be rendered/sent by the server really fast. We may play with that at this time on our local configs, but for drawing basic htm content remotely… I have to say that iframes are much easier/faster and cross-plateform to implement for the moment. Regarding the back-forward thing, I fully agree with Atli but something tells me that back-forwarding with anchor hashes, data cached in each iframes is really fast and enjoying on a navigation point of view so I would prefer to solve the headache with iframes or DOM based framework.

Comment by 0k — March 28, 2009

Leave a comment

You must be logged in to post a comment.