CODEWITHSUNDEEP
javascriptiframewidgetjsonpembedding
sma
sma

Reputation: 407

What is the best re-usable solution for serving complex content (think an entire tree of web pages) from one web app to another website?

Our goal is to let a person, similarly to how you can embed a youtube video, embed a tree of web pages on our SaaS into their own site.

The solution should be good looking, cross-browser, responsive and simple for the end user (ideally, should be search-bot friendly as well).

We are considering two primary options where the customer only needs to copy+paste a code snippet which supports embedding in a portion of the page (ex: the middle column) or full width (ex: everything under a header):

  1. IFRAME: Let the user embed an iframe inside a div, together with a snippet of JS that would resize the iframe as the window is resized.
  2. JS "APP": Let the user paste in a script tag to a JS script/app which would communicate cross-domain (via CORS or JSONP) with our servers.

Ideally, we would like to be able to launch full screen modals from our content.

Questions/concerns for:

IFRAME:

JS "APP":

We would like input on both the:

  1. technical limitations of what’s possible to do
  2. practical hurdles we’d have to overcome going down each path.

p.s. We’re also considering a back-up option, which is to “fake” integration, where we host the content on our site with a subdomain URL (similarly to how Tumblr lets people host their blog on something like “apple.tumblr.com”). If we go down this path we imagine letting the user theme the subdomain. We understand the pros and cons of this path. Downsides are, it’s more work for the user, and they need to keep two different sites in sync visually.

Upvotes: 0

Views: 192

Answers (1)

Marcos Sandrini
Marcos Sandrini

Reputation: 450

I think the best approach is to use the same approach Google and other big companies have been using for quite some time, the embedded script. It is way better looking and semantically unharmful (as an iframe could - arguably - be), and super cross-browser and simple, in fact, just as cross-browser and simple as the code that will be pushed (it can be recommended to be put in a <script async> tag, which will eliminate the need for a crafted async script and, though it won't be as full compatible, it degrades okay and will work very well on most cases).

As to the CORS, if basic cautions are taken, there's no need to worry a lot about it. I would say, though, that if you're planning to do something in Ember or Angular to be embedded, that may be a whole load of scripts/bytes that can even slow down the site/app and impact on the whole user experience, perhaps too much for a component that would be loaded like that. So whenever possible, vanilla JS should always be used in components, especially if Ember/Angular is used because of specific features like binding (specific vanilla JS codes can cover that with much less weight).

Upvotes: 1

Related Questions