Develop Reference

iFrame or a remote JS File

I've got a complex page that can be customized and should be embedded in some clients' websites. For each client it should look the same, but the parameters can be little different. The page also contains a custom object that uses a plugin in the browser.
I had 2 idea to accomplish this:
Using an iFrame - so I just embed my page and pass parameters in the
querystring.
Using a remote JS file - like Facebook SDK and others
work. Passing parameters in the JS code. As I understand, I can just put some 'parent' div on the page and the remote JS file, which should fill the parent div with the needed elements.
Which one should I use? What are the cons / pros of each one?
Thanks!

Take a look at this article which has an in depth look into the ways of what you're trying to achieve.
Pros of IFrame:
If the owner of the mashup page is really concerned with security, malicious scripts running in the widget, then the IFRAME approach is preferable, because the widget’s script will have limited access to the host page and hence couldn’t make much harm to the page where it's embedded into.
Also, this approach is preferable if the owner of the widget wants to control the layout and styling of his/her widget. Since the IFRAME is essentially a separate web page, the mashup’s CSS scripts can’t do much harm to the widget.
Cons:
it is slow, resource intensive [on the browser], and does not give the owner of the mashup page an ability to style the widgets the way s/he wants.

I've had similar issue some time ago. You bassicaly have three options to choose depending how secure and flexible your plugin should be.
iframe
pros
fairly secure - you can present data that should be viewed to specyfic user only and allow passing sensitive data to your service. Page that includes your plugin will not have access to it.
page that includes your iframe will not be able to modify it's content to confuse user
cons
slow
limited communication between your plugin and the page(may be solved by between-window post message/porthole, but this is not perfect)
page still may scam users into beliving they see your plugin, while present own copy or use click jacking
if you include any assets from 3-rd party server that bit of security you had is lost
limited to rectengular box
script
pros
extremly flexible
easy to implement variety of callbacks to react on events on the page
fast
may integrate with interface of the page in many different ways and spots
cons
basically can be modfited in any possible way by page that includes it. You have no controll what users will see in the end.
redirect through your service and then back
pros
most safe solution
cons
hardest to seamlessly integrate
may not interact with other elements of website that uses plugin(since when users see your plugin they are't seeing source website anymore)

JQTouch examples show applications as monolithic one html page creations. Is there a better paradigm for organizing the code?

I'm not a big fan of the way code is organized in the jqtouch examples I can find. So far, all I've seen are monolithic "index.html" files, which contain all the separate views for the iPhone app as separate divs.
Are there any examples out there of better organized jqtouch code?
I'm not looking for generic advice - I'd like to see specific examples of differently organized code.

What you're seeing is usually thought of as a feature of JQTouch, not as a negative "monolithic" style. -- Mobile networks tend to have a large time overhead per http request, so the general idea is to use the one request to download multiple small "pages" (as divs) all at once.
Of course, this paradigm may not fit your use case...
Added Re: alternatives: There are lots of mobile frameworks, see a list or Google. For JQTouch, you can return a response that includes only a single page if you wish to. The reason you're not seeing such examples is because the whole idea of the framework is to make it easy for the developer to return multiple "pages" as a single web server response.
For your server's responses which are a set of mobile pages, the multiple pages-at-a-time trick is the usual approach. For responses which include an infinite scroll page, or which have a lot of dynamic content, you can do Ajax updating of the mobile page, esp if you limit yourself to iPhone and Android browsers.
Overall, the per-request overhead is the big issue for good mobile web app performance. Anytime you can (or probably can) avoid a browser/server round-trip, you should aggressively do so.

JSONP vs IFrame?

Soon I'll be needing to build a widget that some of our clients can embed in their own websites.
To future proof my widget the embed code would be something like this:
<script type="text/javascript" src="path/to/remote/file.js"></script>
<div id="my_widget"></div>
What are the strengths and weaknesses of iframes vs JSONP?
Are there any common SEO based issues with iframes?

First of all, iframes and jsonp are not mutually exclusive: one is a rendering mean, the other is a communication mean.
Your choice is rather between in-document inclusion (that is creating the widget within the host DOM) or in-iframe inclusion (that is having a new, separate DOM for the widget).
The advantage of an iframe is sandboxing: no collision between your widget and the host's javascript and css. That means you can safely:
use/define any javascript library you want
use simple html code together with simple css rules (which is a clear bonus for maintenance)
As for the drawbacks:
an iframe is heavy-weight and may seriously slow down host page rendering
the iframe will also consume much more memory and resources, which may be a problem if the host page is targetted at mobiles
So, if it is reasonable to assume people using your widget will be willing to "adapt" their pages for it, go the in-document way. If not, use an iframe but understand the limits.
As for SEO issues, as long as you dynamically create the widget (whether it's in-document or with an iframe), search engines won't see it. I dunno if that's what you want, but that's what you'll get ;)

Heres some slides from a presentation on cross domain scripting by Alex Sexton
http://www.slideshare.net/SlexAxton/breaking-the-cross-domain-barrier
Unfortunately its just the slides so is missing the accompanying explanations but could be helpful

If you're making API calls and only fetching data, JSONP will result in better performance. If you're rendering things, then you must use iframes. If you want to prevent the host site from access to your widget data, iframes are the way to go. But if your data is public, then JSONP will result in a simpler implementation (since iframes will mean you need to deal with resizing). On the flip side, iframes provide for good CSS sandboxing, so you won't collide with the host page's CSS.

I chose to go with JSONP. You can see the details of how I implemented it here:
if I allow partner sites to republish my RSS feed, will that boost my SEO ranking?
Some people gave their opinions on SEO. I'm still not sure, however, if it helps SEO. I just got an idea to test it though, and I'm going to carry it out right now! I'm going to make a page with just the JavaScript that renders the widget (feed in this case). Then, I'll use Google's Webmaster Tools to see if Google picks up any of the keywords in the feed content. I'll post the answer to the link above after I get the results.
Wish us the best!
Matt

How does disqus work?

Does anyone know how disqus works?
It manages comments on a blog, but the comments are all held on third-party site. Seems like a neat use of cross-site communication.

The general pattern used is JSONP
Its actually implemented in a fairly sophisticated way (at least on the jQuery site) ... they defer the loading of the disqus.js and thread.js files until the user scrolls to the comment section.
The thread.js file contains json content for the comments, which are rendered into the page after its loaded.

You have three options when adding Disqus commenting to a site:
Use one of the many integrated solutions (WordPress, Blogger, Tumblr, etc. are supported)
Use the universal JavaScript code
Write your own code to communicate with the Disqus API
The main advantage of the integrated solutions is that they're easy to set up. In the case of WordPress, for example, it's as easy as activating a plug-in.
Having the ability to communicate with the API directly is very useful, and offers two advantages over the other options. First, it gives you as the developer complete control over the markup. Secondly, you're able to process comments server-side, which may be preferable.

Looks like that using easyXDM library, which uses the best available way for current browser to communicate with other site.

Quoting Anton Kovalyov's (former engineer at Disqus) answer to the same question on a different site that was really helpful to me:
Disqus is a third-party JavaScript application that runs in your browser and injects itself on publishers' websites. These publishers need to install a small snippet of JavaScript code that makes the first request to our servers and loads initial JavaScript loader. This loader then creates all necessary iframe elements, gets the data from our servers, renders templates and injects the result into some element on the page.
As you can probably guess there are quite a few different technologies supporting what seems like a simple operation. On the back-end you have to run and scale a gigantic web application that serves millions of requests (mostly read). We use Python, Django, PostgreSQL and Redis (for our realtime service).
On the front-end you have to minimize your payload, make sure your app is super fast and that it doesn't break in extremely hostile environments (you will be surprised how screwed up publisher websites can be). Cross-domain communication—ability to send messages from hosting website to your servers—can be tricky as well.
Unfortunately, it is impossible to explain how everything works in a comment on Quora, or even in an article. So if you're interested in the back-end side of Disqus just learn how to write, run and operate highly-scalable websites and you'll be golden. And if you're interested in the front-end side, Ben Vinegar and myself (both front-end engineers at Disqus) wrote a book on the topic called Third-party JavaScript (http://thirdpartyjs.com/).
I'm planning to read the book he mentioned, I guess it will be quite helpful.
Here's also a link to the official answer to this question on the Disqus site.

short answer? AJAX, you get your own url eg "site.com/?comments=ID" included via javascript... but with real time updates like that you would need a polling server.

I think they keep the content on their site and your site will only send & receive the data to/from disqus. Now I wonder what happens if you decide that you want to bring your commenting in house without losing all existing comments!. How easy would you get to your data I wonder? They claim that the data belongs to you, but they have the control over it, and there is not much explanation on their site about this.

I'm always leaving comment in disqus platform. Sometimes, comment seems to be removed once you refreshed it and sometimes it's not. I think the one that was removed are held for moderation without saying it.

Are iframes a terrible idea? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm building a widget, and I've been using iframes to present content within it. At some point, I might start serving third party HTML and JS, so I thought iframes would be a good idea.
It does make the widget javascript a little more complicated, and I'm concerned that this might not be the best implementation.
Do you have any advice? It would be a huge help to hear what other people think about iframes.

No, nothing wrong with iframes. Iframes are probably a better idea if you're going to start serving third party content.
The upcoming HTML5 spec also plans to build more security features into iframes for situations like this, so I would consider it good practice to use them now also.

Before XMLHTTPRequest became widely used, people were using a combination of JavaScript and iframes to serve up content in a dynamic fashion without doing full page refreshes.
There's lots of information about developing sites this way so you should have a relatively easy time of it finding workaround to a lot of the snags that you are likely to hit.
The one thing that I have found to be a pain is cross-domain use of JavaScript in iframes. If the page you embed in the iframe is from a different domain than the "parent" page, browsers have security restrictions against letting you access one from the other. The trick is for both pages to declare
document.domain = 'somedomain.com';
There's plenty of stuff on the Web about this kind of workaround.
Good luck!

One thing I discovered recently is that .aspx pages embedded inside iframes sometimes have problems with losing cookies, which led to lost session state in an application I was involved with.
For me, it was in a scenario where a different development shop was consuming one of my .aspx pages in their own page. This means we were on seperate servers, which may or may not be salient.
Apparently this was caused by the parent page rejecting cookies for the child page... As goes the session cookie, so goes the session.
The specific mechanics of how this works are a little involved: More Details
This problem did not impact FireFox, but it did show up in IE7 and it was a real mystery for a few hours.
Also, I have to contradict the article I linked to above on one point. The article says that you don't get this if the containing page is also an .aspx... In this case, that was not true because both pages were .aspxs.
That casts some doubt on everything else the article says about this situation, but it did lead to a resolution, so that's something as well.
As the article suggested, I put in the following code, which injects a p3p (Privacy Preferences Project - I had never heard of it) header in the page's Init event:
HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")
...And that fixed the problem.

I'm going to disagree with the majority and say that yes, iframes are an absolutely terrible idea. Anyone that has worked within the Web Design community for a while will agree that iframes are pure evil and should be avoided unless ABSOLUTELY essential.
My reasons for believing that they are bad is because they break the navigational pattern of a web page. By using an iframe you can effectively break the back and forward buttons on browsers and confuse your users. It breaks the entire idea behind the HTTP protocol; that a URL will always lead to a unique location. If the iframe were a horse it would've retired long ago. There are other ways to serve content dynamically and these should be used instead.
If you're creating a widget then the immediate concerns with using iframes disappear (bad for Search Engines, bad for Bookmarking, etc), but either way content would be better served dynamically or even in a new window rather than in an iframe.

There is only one "really bad" thing with them that I'm aware of.
If your 3rd party does some JavaScript, that attempts to modify their DOM a bit too early... IE6 and IE7 will throw the oh so unhelpful "Operation Aborted" error, then blank out not only the iframe, but the entire surrounding page. (e.g. your site appears down)
It isn't fixed in IE8, but the crash is better handled.

Personally, I'd avoid it if you can without too much hassle. Using Javascript (or AJAX if you need to load them dynamically), you can quite easily just use a div and change the contents as necessary - in some cases this will give you much more flexibility and will simplify your JS, especially if there's a lot of interaction between your widget and the rest of the page.
That said, I'd investigate both options, and if the JS path seems too tricky or complicated, just go with iframes.

In my experience, iframes are either hacks or time-savers - make sure that if you're using them they're neccesary for those reasons. If you have control over the content (or can gain control through mirroring or scraping) you should consider using AJAX or server-side includes to pull external data onto and push it off of the page - it'll end up being more flexible, more robust, and easier to manage in the end.

Depends what the widget does. Iframes have their place, but they do cause few layout headaches (not to mention making your js more complicated) so most people tend to avoid them unless absolutely necessary..

iframes, like frames, are just controls to use for the task at hand. As such, it is neither good nor bad in itself, but could be good or bad based on the task at hand and the client's requirements. As far as I know, all modern browsers (and non-linux users) will be able to "see and consume" iframes without a problem.

A good option is to use the overflow CSS property. The default value is visible but you can set it to hidden, scroll or auto. I would use auto in your case. If your content gets too big it will look like you have an iframe but it is still right on the page.
see: overflow property

Iframes are not evil they are just another tool like anything else and to determine their merits you have to determine the context in which they will be used. Google Image Search, and several other high profile sites, use iframes for limited purposes.
In general I find they are used for branding or to enable a user to return to a site that redirects the user off site.
Note, if you are using cross domain iframes e.g. an iframe that refers to a domain outside where the page is being served you are limited by design for security reasons and cannot access through javascript the internals of a DOM outside the domain it is associated with.
Also please note many sites prevent their site from being embeded and will stripe the iframe off (redirecting the top url to their domain).

Not necessarily, as long as the content within the iframe is predictable.

Technically there is nothing wronger with iFrame that with alternatives. But semantically, there are evil.
The Web is based on HTTP, a protocol that says a given URL will always leads to a unique ressource.
Using iFrame, you just serve several ressources melted in a web pages behind one URL for all of them. If you have concerns about how the Web should grow, it's troublesome. What's more, for the search engine robots, it's tricky.

There are several usability and accessability issues with iframes. Some browsers and screenreaders can not display iframes, so you should provide alternative content:
<iframe src="content.html">
<p>
This content will only be displayed by browsers that do not support
iframes. You should provide a link to the content, or in your
case an alternative way to use your widget.
</p>
</iframe>
If you start serving third party content, you should watch out for the iframe grabbing focus after it has finished loading. While a minor annoyance for regular users, it can be very confusing for users browsing with screenreaders.

Re: "the entire idea behind the HTTP protocol; that a URL will always lead to a unique location"
I serve my entire CMS from the same URL for security and scaleability (using mostly POST instead of GET parameters). I don't want secure content visible without authentication, and a dispatch system makes development easier for me as I don't have to worry about authentication for every new page.
Also, for some applications SEO is not applicable (such as for web-based ERP).
I use an iFrame for serving content from a PHP generated assembly tree. I don't want the tree (and node visibilities) refreshed whenever the user wants to view details for a part/assembly.

There is a significant issue with iframes that hardly gets a mention but which bugs the stuffing out of me.
Our colleague has a lifetime of work invested in a dynamically changing database which we have loaded into Google Docs spreadsheets which we then display on our site alongside a lot of supporting material.
There is absolutely nothing to stop someone grabbing the iframe code out my page source and shoving it onto their page. Now they are getting all our data, refreshed right up to a few minutes ago, served to their page for absolutely nothing at all.
If a google iframe could be tied to a specific domain, that would stop that in its tracks.
Any ideas, bright sparks?