Why iframes in rich web applications are evil

I write this post claiming to heavens that you (as a web developer figuring out whether to use or not iframes) will read and follow my advice. Not only for me, nor for you, but for a better world.

Let’s say you are in charge of porting a desktop application to the web environment; you have to change the paradigm and start using CSS, JS (lukily even a framework like Dojo) and finally HTML. Your webapp has menus, submenus, a lot of stuff and many different forms, interfaces and views to present and collect the information to and from the user.

And at some point you discover what iframes are, and may you think “they might well pay the effort, I can create every single interface separately and finally integrate them into the full framework, like a puzzle”. Don’t. They are not worthy, and you’ll find out why too late. Seriously, while iframes are useful in some practical situations (when there is absolutely no other solution), they bring in some major drawbacks when used to build the interfaces of your rich web app:

  • The JS top layer application does not know about, and therefore cannot access, the DOM elements in inner frames.
  • CSS heritance is not respected, so there is no way to ensure what the inner frame is going to look like – unless CSS files are loaded again (see below).

As a consequence of this two effects, both related to the very nature of an iframe (to load an external page into your site), every CSS and JS file must be loaded again in every inner frame so that the app can run, which produces a waste of server’s resources and slows the page load, which in turn impacts on user experience. Of course you can compile your files in production to alleviate this, but it is not going to fix the maintenance problems and the hacks and turnarounds that you’ll need to apply in order to get your web app working as expected. Not to talk about big applications: centralizing the logic of your SAAS in one main class is going to be very painful due to the limitations said above. And not centralizing such kind of huge logic (that’s to say, classical event-driven approach) can turn your best efforts to create a coherent code into a considerable mess. When your application grows and you realize about these limitations, there is not going to be a turnaround, and you’ll have to deal with an unstoppable monster.

Yeah, yeah, I know: they come in handy; they are easy to implement; they are useful and shinny; but moreover, they are very, very evil. Please, stop using them! If you ever have had to refactor a medium sized JS application based on iframes, you surely know what I’m talking about… otherwise, please, do yourself a favor (and to the ones that will come after you) and avoid those damn iframes. Please! I beg you!

Further reading:

5 thoughts on “Why iframes in rich web applications are evil

  1. Yes, you can, for sure, but that’s not the issue. Iframes are not a problem for medium-size interfaces based on a distributed architecture of widgets or components (that’s to say, 80% of current web sites). Vice versa works too, you can access the DOM in the parent frame (although you have to explicitely know the iframe where the resource is, which can be a bit of drawback sometimes).

    The real issue comes with medium-big web applications when distributed designs tend to be a mess, and centralized architectures are very limited by problems related to the very nature of iframes. There is not a simple way of having a single background application managing modules and sections, because every frame means a different DOM object and variables. While both can be accessible from other parts of the interface, their context is never the same, and therefore determining where to apply a value or look for a node can be a pain if you want to do it dynamically.

    Not to talk about resources: both JS and CSS files must be loaded as many times as iframes are on your app. That’s allright for jQuery and a couple of plugins in a zipped file of 30KB, but it is not for bigger dependencies which produce much bigger amount and load of files. I am currently working on an application with literally hundreds of resource files which make several MB even packed, and it is very difficult to spot what you want when you want it within a forest of iframes from a single centralized JS application.

    Anyway, to be honest it is not fair to say iframes are evil by themselves… it depends most on the way the are used and the type and size of the web site relying on them.

    Thanks for your comment!

  2. Iframes are often used in conversion processes, but can make it very hard to implement conversion tracking.

    Especially if the iframe’s content runs on another website, or – heaven forbid! – an IP address.

    Not the mention the negative side effects on SEO…

    “Run, Forrest, run!”

  3. An excellent use of iFrames is in a payment application that is not PA-DSS verfied. We use iFrames to insulate the the credit card number from the application. Our product, TokenCard(tm) uses an iFrame embeded in the application to accept a user entered card number without it being exposed to the application. The iFrame is hosted on our PCI-DSS verified system and provides a token to the application that has no meaning outside of the TokenCard(tm) system. By using TokenCard(tm) and the iFrame, your application does not have to be PA-DSS verified as it no longer handles, stores or transmits credit card numbers. Getting authorization and payment with TokenCard(tm) is as simple as transmitting the Token to our payment servers.

  4. I know this thread is 3 years old BUT, I am very interested in what Richard Cowan did with iFrames because that is essentially what I am trying to do. A Google search of “TokenCard” and his name shows that the trademark TokenCard is dead, no longer an operating business, and I do not have an email for Richard Cowan.

    Can anybody give more information on how the process would work?


Leave a Reply

Your email address will not be published. Required fields are marked *