We Keep Coding

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):
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.
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:
Can an iframe reliably update the URL of the parent’s browser window?
Can we reliably launch full screen modals from an iframe?
Can we reliably get the iframe to resize when the window is resized or iframe content changes?
JS "APP":
How significant is the overhead of dealing with properly encapsulating our app to avoid naming/library conflicts? For example, we will ideally stick to vanilla JS but if we want to use a library like Ember and a customer of ours has an Ember site.
Any non-obvious cross domain gotchas? We will be using CORS or JSONP.
We would like input on both the:
technical limitations of what’s possible to do
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.

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).

How to manipulate the DOM before the browser starts downloading assets?

I want to serve the same DOM to all browsers and devices, e.g. desktop, tablet, phone, etc. However, I do not want the assets (images, stylesheets, etc.) intended only for desktop to be downloaded on mobile and waste HTTP requests and bandwidth.
Is there any way to manipulate the DOM before the browser starts downloading the assets, using strictly client-side Javacript, depending on the device and browser?
I feel like using the DOMContentLoaded event (https://developer.mozilla.org/en-US/docs/Web/Events/DOMContentLoaded) gets me close..
EDIT: I have found that mobify.js seemingly does what I am after: https://www.mobify.com/mobifyjs/v2/docs/
They provide a 'Capturing API for manipulating the DOM before any resources have loaded'. It also appears to be done with client-side Javascript. Will have to look through their source on GitHub to see how they are doing it.

One easy option to send device appropriate images is adaptive images. It will resize the images based on break points you set, and on your visitors' screen size.
What I particularly like about this specific solution is that it's also easy to instal to an existing site. You can try it out and if it's a good fit for your site then you are off.
There are some JS techniques to send different CSS files based on screensize or viewport. I have used one in the past, but FWIW I've found that if you minimize and compress your CSS files, there's little be gained and it only adds a layer of complexity. Your time is much better spent trying to save bandwidth on your images.
EDIT
Another possibility that might might work well for you is the newer srcset attribute, a couple of links to get you started:
http://css-tricks.com/video-screencasts/133-figuring-responsive-images/
http://martinwolf.org/2014/05/07/the-new-srcset-and-sizes-explained/
Good luck!

The only thing I could think about it is kinda naive and implies the use of "document.write" to include the "img" tags just for desktop connections. However, you also point that you want the same DOM for all devices, whereas there will be javascript elements in this case. Unfortunately you don't want to do it from server side which would be easier and clean.

Is there a way to downscale images so load time isnt massively bogged down

I'm writing a gallery application that pulls images from an rss feed, so editing the images directly isn't an option.
Unfortunately some of the galleries are quite large because the files were uploaded as a large scale.
Is there a way to make sure when the images are loaded to have them load at a reasonable size with javascript/jquery?
Thanks for your help as always!
Oh also- if im linking these images directly from the rss to the site they originated from, say- a google rss feed, can that land me in any trouble with them loading a bunch of images off their site?

With just javascript / jquery, no.
Assuming that storing the images on your server isn't an option, you would have to use a server side script like php to load the image on your server, scale it down and deliver that to the browser.
So your client side script would be something like
$("#myImgTag").attr( 'src', 'http://yourserver.com/getRSSimage.php?url=google.com/rss/reallyBigImage' );
As to the legality of linking directly, its a legal gray area. If you try to state that the images are yours, then yes its illegal, however, clearly showing where the images came from giving all necessarily credit, that's considered ok especially if you're not making money from it.

Is there a way to make sure when the images are loaded to have them
load at a reasonable size with javascript/jquery?
No
if im linking these images directly from the rss to the site they
originated from, say- a google rss feed, can that land me in any
trouble with them loading a bunch of images off their site?
Yes

What you are asking for would be server-side operation. jQuery in the client browser can only operate on the images after they have been received in the browser. To download smaller images, you would need to either:
1) Learn how to request smaller images from the site rather than the larger sizes. For example, if the RSS feed was from a photo site like Smugmug, the image URLs can be modified to request a smaller size.
2) Modify the server to support a request for a smaller size (I presume this is not an option for you).
Whether what you are doing will get you into trouble depends on more of the details of what you are doing. A site on the web with public images and a public RSS feed is allowing some fair use of those, but is not allowing unlimited use for any purpose. We would have to know a lot more specifics.

Short answer: no not really. even logically, such transformation has to occur somewhere, and you have to do so to the original. That being the case, since you have to load the original anyway, there is no point to re-sizing it. And as for hotlinking, I don't think it's illegal, but the site that you are hotlinking from will hate you for it.

If the gallery always uses the same RSS feed, you could look into scaling and storing the images on the server. When a user visits your gallery, a simple check could be made for whether the "thumbnail" image is available and to load that one instead. That would require a little JavaScript / AJAX, and you'd have to write some code to scale and store images.
This really isn't ideal though. Scaling and storing images is both processor and memory intensive. If you're serving lots of users and lots of images, this isn't going to scale well. I don't see any problem with you pulling lots of images from a server... that's what they're there for right? Just make sure you're not being wasteful with your requests and respecting the bandwidth of the server.

The other answers are correct in that the image optimization would need to be done server-side. There are some tools that can do this work for you, however, which would enable you to serve optimized images just by modifying the image src that you're assigning through JS.
Take a look at http://www.punypng.com/api for an example.
Take note that this isn't ideal, though, since you're relying on the resources/etc of an outside server to serve images.

What's better? More HTTP requests = less data transfered or Less HTTP requests = more data transferred?

Sites like Facebook use "lazy" loading of js.
When you would have to take in consideration that I have one server, with big traffic.
I'm interested - which one is better?
When I do more HTTP requests at once - slower loading of page (due to limit (2 requests at once))
When I do one HTTP request with all codes - traffic (GB) is going high, and apaches are resting little bit more. But, we'll have slower loading of page.
What's faster in result ?

Less requests! Its the reason why we combine JS files, CSS files, use image sprites, etc. You see the problem of web is not that of speed or processing by server or the browser. The biggest bottleneck is latency! You should look up for Steve Souders talks.

It really depends on the situation, device, audience, and internet connection.
Mobile devices for example need as little HTTP requests as possible as they are on slower connections and every round trip takes longer. You should go as far as inline (base-64) images inside of the CSS files.
Generally, I compress main platform and js libs + css into one file each which are cached on a CDN. JavaScript or CSS functionality that are only on one page I'll either inline or include in it's own file. JS functionality that isn't important right away I'll move to the bottom of the page. For all files, I set a far HTTP expires header so it's in the browser cache forever (or until I update them or it gets bumped out when the cache fills).
Additionally, to get around download limits you can have CNAMES like images.yourcdn.com and scripts.yourcdn.com so that the user can download more files in parallel. Even if you don't use a CDN you should host your static media on a separate hostname (can point to the same box) so that the user isn't sending cookies when it doesn't need to. This sounds like overfill but cookies can easily add an extra 4-8kb to every request.
In a developer environment, you should be working with all uncompressed and individual files, no need to move every plugin to one script for example - that's hard to maintain when there are updates. You should have a script to merge files before testing and deployment. This sounds like a lot of work but its something you do for one project and can reuse for all future projects.
TL;DR: It depends, but generally a mixture of both is appropriate. 'Cept for mobile, less HTTP is better.

The problem is a bit more nuanced then that.
If you put your script tags anywhere but at the bottom of the page, you are going to slow down page rendering, since the browser isn't able to much when it hits a script tag, other then download it and execute it. So if the script tag is in the header, that will happen before anything else, which leads to users sitting there stairing at a white screen until everything downloads.
The "right" way is to put everything at the bottom. That way, the page renders as assets are downloaded, and the last step is to apply behavior.
But what happens if you have a ton of javascript? (in facebooks example, about a meg) What you get is the page renders, and is completely unusable until the js comes down.
At that point, you need to look at what you have and start splitting it between vital and non vital js. That way you can take a multi-stage approach, bringing in the stuff that is nessicary for the page to function at a bare minimum level quickly, and then loading the less essential stuff afterwards, or even on demand.
Generally, you will know when you get there, at that point you need to look at more advanced techniques like script loaders. Before that, the answer is always "less http requests".

Why some professional web designers use absolute paths instead of relative paths (e.g for CSS, Javascript, images, etc.)?

I used to think that everyone used relative paths (e.g. /styles/style.css). But I wonder why some popuar web designers (e.g. http://www.getfinch.com and http://31three.com/) use absolute paths (http://example.com/styles/style.css).
So basically I'm asking why some professional designers are using absolute paths instead of relative paths?

Both of those are using ExpressionEngine CMS, it's probably the way the CMS links the stylesheets.
But really it's just a matter of preference. Personally I go with root relative /css/main.css because this way if I'm developing locally + offline I don't have to worry about switching the WEB_ROOT constant to a local one ( less hassle + shorter ).
The only case I see for absolute is if the domain uses a CDN ( content delivery network ) and the domain is different from the origin domain.

Good thread on Google Webmaster Central... Discusses about Google crawling perspective and easy of migration.
Relative Path vs Absolute Path

Relative Paths
I don't think either make too much of a difference. Using relative paths is easier while working offline and then uploading the website.
Also if you were to ever change the domain and want to still keep your site. You will only need to change the absolute links that you have referenced, the relative links will work just fine.
Absolute Paths
A browser can only download 2 files from a server at any given point of time. Also, while it downloads JavaScript it does not download anything else. So to circumvent this 2 file limit, a lot of people use sub domains. like : http://css.example.com/style.css -- this is to increase page load speed. You can't achieve this effect using relative URLs.
One place where you will need to be careful of your absolute paths is when you are making AJAX calls. If you hard code into your javascript, a call to the url : http://www.example.com/ajaxfile.php -- the AJAX call will work fine from http://www.example.com/index.php but not from http://example.com/index.php -- this is because of the same origin policy.

I would say either personal preference (most likely), or portability, if your files are referencing a fully qualified URL you don't need to include those files when using the html elsewhere, it'll continue pulling from the remote site.
It depends more on the platform than anything else in my experience, for example .Net uses ~/ for application root, which renders as /path/file.css in the HTML, just because that's an easy path to render from the code side...path of least resistance deal there.
Another case would be if you're loading stuff from another domain, for example sstatic.net here, you don't have a choice really, it has to be fully qualified.

I think it's only a matter of preference. I prefer relative URLs because it's less of a pain to change if you're changing (sub)domains. But if you have a CMS or blog it usually handles that for you anyways (e.g. {SITE_URL}/path/to/page).

I think some Apache Redirect Rules have problems with relative paths. Choosing the absolute path assures that the .htaccess file is hit.

Not sure about those specific sites, but often people use different urls for static resource files for efficiency purposes (not personal preference). Most browsers have a limit on the number of concurrent connections to a single url while loading the page, and you can bypass that restriction by serving files some files from a different url, which would require an absolute path. This helps pages load faster and is a common practice.

Aside from the obvious portability issues, absolute paths are not a good idea if the content is on the same domain because it can cause extra DNS lookups in certain browsers. Keeping domains relative to the root of your site whenever possible can help boost performance unless you have a CDN or separate set of domains to host static content from.
Hope this helps!

Also, sometimes, if the code is server-side, there may be a variable that is printing out the full URL. If I remember correctly, usually in WordPress themes that is how they output the proper directory.

Some people would even say that paths that start from a domain's root (e.g. /styles/style.css ) are absolute (and, consequently, problematic).
Here's the thing: both absolute/fully qualified schemes and relative schemes solve problems related to what happens when you move things around. But they solve different problems. With a fully relative scheme, you can move everything related to the document around to a different path on the server and you won't break things. With a fully qualified (and some absolute schemes), you can move any individual document around and not break things.
I tend to find that I move things in groups more often than I migrate an individual document, so I tend to use fully relative schemes. Other people may have different needs.

The reason I always have heard is that it is for SEO optimization when linking to pages on the same domain. I am not sure if this is something kept from the dark ages of web development or if this is still true but this is the rationalization I am always given.
The way I get around this is I use the base attribute in my header so that I can get the benefit of relative urls. This way I can test on my development server and just change the base url or comment it out completely. Although all your relative urls will need to be written like they are navigating from the base url set.

If your page gets called using https protocol, any relative path css will be called using https protocol as well. Are you really need to encrypt/decrypt css contents? :D
However, if you use absolute path referring to an external css, you can specify the protocol to use, generally http rather than https.

it depends on the application that you are building, for example. your application uses mvc framework, like the one in your example, they have to use absolute paths because the css they are calling does not belong to the relative path in each page.
EDIT
using mvc framework does not mean you have to use absolute paths but you can also use relative paths. This is just my preference.