Are you afraid of iFrames?

You’re calmly working in your next frontend application, using all kinds of new frameworks that ease your daily tasks and make the development process so natural and understandable. Everything is fun, until you hear words like “Internet Explorer”, “hard coding”, “DOM manipulation” … or even worse: “iFrames.” No, please!

“iFrames.” That’s a word we don’t like to hear, ever. We all know what iFrames imply:

• They look horrible (like those stickers some people put on their laptops. I’m sorry, I can’t deal with it :P )
• They have several attributes that aren’t supported in html5 anymore.
• Sometimes you have to use scrollbars to see the hidden content.
• If you want to display content from another website, you can‘t control what happens there and you could have serious security issues.

Few experienced developers feel comfortable when their managers or customers require them to use iFrames. But anyway, let’s forget about them for a while.

Now, imagine some customer wants to embed your application inside their own website. Ok, no problem, we tell this to the customer:

“Here you have the minified files. Import the js files, also the CSS ones. Select a <div> node in your DOM to insert my app and then use the javascript functions described in the documentation I sent you (or use the React custom components if the app is built with that framework). Please, also provide the dimensions of the space left for my app so it can be responsive.”

So far, so good. The integration is quite easy and the customer’s website displays our application nicely and, let’s say it, beautifully. Easy, right? Well, that’s the scenario we all want when integrating our app, but being honest, normally, the process isn't that quick and easy to accomplish. In a standard situation, we’ll have to face several headwinds:

• The customer website uses some of the same js libraries we use in our app, so we have collisions with some of the functionalities and unexpected things happen. Even worse, the client app uses quite an old version of the library. Why would someone do that? Come on. Please don’t do that.
• The parent application uses generic CSS rules for <span> elements, or <p>, or maybe some class names coincide with ours. As a result, our app ends up looking completely different.
• Our app was responsive. We tested it with different widths and it looked great. But now it doesn’t. We defined some breakpoints for different devices but when embedding the app, the reference width isn’t similar to the width of the app anymore, but similar to the width of the parent application. So our breakpoints references have to change if we want our “mini-app” to be responsive.

Too many problems, too little time to have the app in production. Anxiety starts to hit.

How we can we avoid these issues in future integrations?

Hi! I’m an iFrame and I want to be your friend!

Developer: “Wait … why would I want to use that piece of ****?”
iFrame: “Let me summarise some of my features!”

And then, the iFrame said:
- You won’t have libraries collisions anymore because I behave like another tab/window.
- You won’t have CSS collisions anymore because I behave like another tab/window.
- Your app will remain responsive because its breakpoints’ reference is the iFrame’s width, not the main window’s one.

Wow. How come I didn’t think about that before? This seems ideal for the integration of frontend apps. But wait, what about the cons of using iFrames?

Well, you can minimize the risks and problems of using iFrames this way:

• If you think iFrames don’t look good, you have several attributes like “frameborder” or “scrolling” to make them look nicer. They are not supported in html5, but, unless the customer wants a 100% html5 app (which would be unusual), this wouldn’t be a problem.
• You have the “sandbox” attribute to control some risks, such as allowing forms, scripts or other potential issues inside the iFrame.

To sum up, iFrames aren’t ideal, and if you can avoid them, please do. But in some cases, especially when integrating a frontend app inside another one, they can provide more advantages than drawbacks.

Don’t fear the iFrame, be his friend. But just for a while.