Skip to content

Instantly share code, notes, and snippets.

@zealoushacker

zealoushacker/why_iframes_are_good_for_widget_development.md

Last active September 7, 2015 14:35
Show Gist options
  • Save zealoushacker/88c17e7c89b081b7772c to your computer and use it in GitHub Desktop.
Save zealoushacker/88c17e7c89b081b7772c to your computer and use it in GitHub Desktop.
Download ZIP
Why iframes are great for embeddable widget development
Raw
why_iframes_are_good_for_widget_development.md

Why iframes are good for embeddable widget development

There are generally two ways to build embeddable widgets to be embeddable by an arbitrary widget consuming site, that isn't on the same domain as where the widget is hosted (think stripe checkout, olark chat, or zendesk support widgets as examples):

  1. Render the widget into the embedding site's designated <div> or some other html container element
  2. Render the widget into the embedding site's designated <iframe> element

To be sure, <iframe> is generally a pretty horrible way to go. But, as usual there are tradeoffs, and in one very specific use case, it's pretty great: building embeddable widgets. No, it's not because most other companies of any import that build widgets, with some very smart engineers, use the <iframe> method - I am not one for appeals to authority - and there are some notable exceptions, like olark, though they are probably hating the maintenance of the widget ui and associated css. Primarily, the core reasons why <iframe> elements are great containers for embeddable widgets are:

  • Huge: no SPOF problem, because loading and rendering an iframe content happens separately from its embedding site's content. Yes, it could be a white box if the widget fails, but it would never block the rendering queue of the embedding site, especially when used with loading the JS interface API for the widget asynchronously. Never.
  • Complete and total control over widget CSS and HTML with no possibility of CSS clashes between the site embedding the widget, and the site serving the widget, thus solving all sorts of possible layout problems, unpredictable color changes, etc.
  • Complete and utter impossibility of clashes or "accidental" control over the widget UI via JS from the site embedding the widget, because the widget <iframe> is sandboxed and follows same-origin rules. What this means is that the embedding site may not control anything in the widget, without the widget exposing an explicity same-origin js-based interface to do so.
  • Creating a very clean and unbreakable interface between the embedding site and the iframed widget, via js.
  • Ease of maintenance of widget code, without having to worry about the plethora of special cases related to CSS bleeding issues.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment