Widget - Iframe versus JavaScript

I have to develop a widget that will be used by a third party site. This is not an application to be deployed in a social networking site. I can give the site guys a link to be used as the src of an iframe or I can develop it as a JavaScript request.

Can someone please tell me the trade offs between the 2 approaches(IFrame versus JS)?

I was searching about the same question and I found this interesting article:
http://prettyprint.me/prettyprint.me/2009/05/30/widgets-iframe-vs-inline/

> Widgets are small web applications that can easily be added to any web > page. They are sometimes called Gadgets and are vastly used in growing > number of web pages, blogs, social sites, personalized home pages such > as iGoogle, my Yahoo, netvibes etc. In this blog I use several > widgets, such as the RSS counter to the right which displays how many > users are subscribed to this blog (don’t worry, it’ll grow, that’s a > new blog ;-) ). Widgets are great in the sense that they are small > reusable piece of functionality that even non-programmers can utilize > to enrich their site. > > I’ve written several such widgets over the time both “raw” widgets > that can get embedded in any site as well as iGoogle gadgets which are > more structured, worpress*, typepad and blogger widgets, so I’m happy > to share my experience. > > As a widget author, for widgets that run on the client side (simple > embeddable HTML code) you have the choice of writing your widget > inside an iframe or simply inline the page and make it part of the dom > of the hosting page. The rest of the post discusses the pros and cons > of both methods. > > How is it technically done? How to use an iframe or how to implement > an inline widget? > > Iframes are somewhat easier to implement. The following example > renders a simple iframe widget: > > frameborder=’0′ is used to make sure the ifrmae doesn’t have a border > so it looks more natural on the page. The > http://my-great-widget.com/widget is responsible of serving the widget > content as a complete HTML page. > > Inline gadgets might look like this: > > function createMyWidgetHtml() { return "Hello world of widgets"; } > document.getElementById('myWidget').innerHTML = createMyWidgetHtml(); > As you can see, the function createMyWidgetHtml() it responsible for > creating the actual widget content and does not necessarily have to > talk to a server to do that. In the iframe example there must be a > server. In the inline example there does not need to be a server, > although if needed, it’s possible to get data from the server, which > actually is a very common case, widgets typically do call server side > code. Using the inline method server side code is invoked by means of > on-demmand javascript. > > So, to summarize, in the iframe case we simply place an iframe HTML > code and point the source of the iframe to a sever location which > actually serves the content of the widget. In the inline case we > create the content locally using javascript. You may of course combine > usage of iframe with javascript as well as use of the inline method > with server side calls, you’re not restricted by that, but the paths > start differentially. > > So what is the big deal? What’s the difference? There are several > important differences, so here starts the interesting part of the > post. > > Security. iFrame widgets are more secure. > > What risks do gadgets impose and who’s actually being put at risk? The > user of the site and the site’s reputation are at risk. > > With inline gadgets the browser thinks that the source of the gadget > code code comes from the hosting site. Let’s assume you’re browsing > your favorite mail application http://my-wonderful-email.com and this > mail application has installed a widget that displays a clock from > http://great-clock-widgets.com/. If that widgets is implemented as an > inline widget the browser thinks that the widget’s code originated at > my-wonderful-email.com and not at great-clock-widgets.com and so it’ll > let the widget’s code ultimately get access to the cookies owned by > my-wonderful-email.com and the widget’s evil author will steal your > email. It’s important to realize that browsers don’t care about where > the javascript file is hosted; as long as the code runs on the same > frame, the browser regards all code as originationg at the frame’s > domain. So, you as a user get hurt by losing control over your email > account and my-wonderful-email gets hurt by losing its reputation. > > If the same clock would have gotten implemented inside an iframe and > the iframe source is different from the page source (which is the > common case, e.g. the page source is my-wonderful-email.com and the > gadget source is great-clock-widgets.com) then the browser would not > allow the clock widgets access to the page cookies, nor will it allow > access to any other part of the hosting document, including the host > page dom. That’s way more secure. As a matter of fact, personal home > pages such as iGoogle don’t even allow inline gadgets, only iframe > gadgets are allowed. (inline gadgets are allowed only in rare cases, > only after thorough inspection by the iGoogle team to make sure > they’re not malicious) > > To sum up, iframe widgets are way more secure. However, they are also > way more limited in functionality. Next we’ll discuss what you lose in > functionality. > > Look and feel In the look and feel battle inline gadgets (usually**) > win. The nice thing about them is that they can be made to look as > part of the page. They can inherit CSS styles from the page, including > fonts, colors, text size etc. Iframes, OTHO must define their CSS from > the grounds up so it’s pretty hard for them to blend nicely in the > page. > > But what’s even more important is that iframes must declare what their > size is going to be. When adding an iframe to a page you must include > a width and a height property and if you don’t, the browser will use > some default settings. Now, if your widget is a clock widget that’s > easy enough b/c you know exacly what size you want it to be, but in > many cases you don’t know ahead of time how much space your widget is > going to take. If, for example you’re authoring a widget that displays > a list of some sort and you don’t know how long this list is going to > be or how wide each item is going to be. Usually in HTML this is not a > big deal because HTML is a declarative based language so all you need > to do is tell the browser what you want to display and the browser > will figure out a reasonable layout for it, however with iframe this > is not the case; with ifrmaes browsers demand that you tell it exactly > what the iframe size is and it will not figure it out by itself. This > is a real problem for widget authors that want to use iframes – if you > require too much space the page will have voids in it and if you > specify too little the page will have scrollbars in it, god forbids. > > Look and feel wise, inline wins. But note that this really depends on > your widget application. If all you want to do is a clock, you may get > along with an iframe just as well. > > Server side vs. Client side IFrmaes require you specify a src URL so > when implementing a widget using an iframe you must have server side > code. This could both be a limitation and a headache to some (owning a > server, domain name etc, dealing with load, paying network bills etc) > but to others this is actually a point in favor of iframes b/c it > let’s you completely write your widgets in server side technologies, > so you can write a lot of the code and actually almost all of it using > your favorite server side technology whether it be asp.net, django, > ror, jsp, struts , perl or other dinosaurs. When implementing an > inline gadget you’ll find yourself more and more practicing your > javascript Ninja. > > What’s the decision algorithm then? Widget authors: If the widget can > be implemented as an iframe, prefer an Iframe simply for preserving > users security and trust. If a widget requires inlining (and the > medium allows that, e.g. not iGoogle and friends) use inline but dare > not exploit users trust! > > Widget installers: When installing a widget in your blog you don’t see > a “safe for users” ribbon on the widgets. How can you tell if the > widget is safe or not? There are two alternatives I can suggest: 1) > trust the vendor 2) read the code. Either you trust the widget > provider and install it anyway or you take the time to read its code > and determine yourself whether it’s trustworthy or not. Reality is > that most site owners don’t bother reading code or are not even aware > of the risk they’re putting their users at, and so widget providers > are blindly trusted. In many cases this is not an issue since blogs > don’t usually hold personal information about their readers. I suspect > things will start changing once there are few high profile exploits > (and I hope it’ll never get to it). > > Users: Usres are kept in the dark. Just as there are no “safe for > users” ribbons on widgets site owners install, there are no “safe to > use” sites and basically users are kept in the dark and have no idea, > even if they have the technical skills, whether or not the site they > are using contains widgets, whether the widgets are inline or not and > whether they are malicious. Although in theory a trained developer can > inspect the code up-front, before running it in her browser and losing > her email account to a hacker, however this is not practical and there > should be no expectation that users en mass will do that. IMO this is > an unfortunate condition and I only hope attackers will not find a way > of taking advantage of that and doom the wonderful open widget culture > on the web. > > Happy widgeting folks! > > * Some blog platforms have a somewhat different structures for widgets and they may sometimes have both widgets and plugins that may > correlate in their functionality, but for the matter of the discussion > here I’ll lously use the term widget to discuss the “raw” type which > consists of client side javascript code > ** Although in most cases you’d want widgets to inherit styles from the hosting page to make them look consistent with it, sometimes you > actually don’t want the widget to inherit styles from the page, so in > this case iFrames let you start your CSS from scratch.

Why not doing both ?

I prefer to offer third party sites a script like:

 <script type="text/javascript" src="urlToYourScript"></script>

the file on your server looks like :

document.writeln('<iframe src="pathToYourWidget" 
name="MagicIframe" width="300" height="600" align="left" scrolling="no" 
marginheight="0" marginwidth="0" frameborder="0"></iframe>');

UPDATE:

one disadvantage of using an iframe that points to an url on your server is that you do not generate a "real" backlink if someone clicks on an url from your server pointing to your server.

I'm sure many developers/site owners would appreciate a Javascript solution that they can style to their needs rather than using an iframe. If I was going to include a component from a third party, I would rather do it via Javascript because I would have more control.

As far as ease of use, both are similar in simplicity, so no real tradeoff there.

One other thought, make sure you get a SSL cert for whatever domain you're hosting this on and write out the include statement accordingly if the page is served over SSL. In case your site owners have a reason for using SSL, they would surely appreciate this, because Firefox and other browsers will complain when a page is served with a mix of secure/insecure content.

If the widget can be embedded in an iframe, it will be better for the frontend performance of the hosting site as iframes do not block content download. However, as others have commented there are other drawbacks to using iframes.

If you do implement in javascript, please consider frontend performance best practices when developing. In particular, you should look at Non blocking javascript loading. Google analytics and other 3rd party widget providers support this method of loading. It would also help if you can load the javascript at the bottom of the page.

Nice to know that it's not to be deployed in a social networking site... that merely leaves the rest of the web ;-)

What would be most useful depends on your widget. IFrames and javascript generally serve quite different purposes, and can be mixed (i.e. javascript inside an iframe, or javascript creating an iframe).

• IFrames got sizing issues; if it's supposed to be an exact fit to the page, do you know that it renders the same on all browsers, the data won't overflow it's container etc?
• IFrames are simple. They can be a simple, static HTML-page.
• When using IFrames, you expose your widget quite plainly.
• But then again, why not have your third party site simply include the HMTL at a given url? The HTML can then be extended to contain javascript when/if you need it.
• Pure Javascript allows for more flexibility but at the cost of some complexity.

The big plus of iframes: all CSS and JS is separated from the host page, so your existing CSS just works. (If you want the host site to style your content to fit in, that's a minus of course.)

The big minus of iframes: they have a fixed width and height and scroll-bars will appear if your content is larger.