April 3, 2011

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: