Many developers choose a very easy approach when creating applications to be portable from one container to the next: serving up the entire application in a single iframe. With this method, the application being loaded is a page on the developer server. Both Facebook and OpenSocial allow developers to use a standard HTML iframe, which means that when the application is ported from Facebook to OpenSocial, none of the code needs to be modified to serve it up.

The major problem with this approach emerges when you try to leverage the client-side methods and constructs, as well as potential container-specific tags, within the iframe content. By simplifying the cross-container development efforts, you lose the easy-to-use features that containers provide for accessing a user’s social details, such as the OpenSocial JavaScript libraries and methods. There are methods you can use to pass along OAuth access tokens to the iframe to sign requests to the container REST URIs, but working with social profile data becomes far more complicated.

You can think of iframes in an application in a similar way to a surgeon’s tools. The surgeon has a few options available to her; she can use a butter knife or a scalpel. Both tools will eventually do the job, but one is much messier than the other. The butter-knife approach in our scenario is encasing the entire application in an iframe. Using the scalpel approach, we can selectively introduce iframes where appropriate.

This raises the question: when is the appropriate time to use an iframe? The simple answer is that you should use iframes to wrap sections that do not require the container user’s social data—for example, when generating nonsupported HTML or JavaScript constructs in Facebook.