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.

Developing a simple web designer (drag + drop of text /w fonts and images)

I have a client who has requested I develop a simple web designer (ala CustomInk.com's t-shirt designer) which allows users to drag & drop text and uploaded images onto a canvas.
I have some ideas about getting started with javascript/jQuery but I wanted to ask SO: What is the most universally accessible way (in terms of browser support etc.) of developing an editor like this?
Does anyone have any advice/experience in the matter before I start fooling around blindly?

For cross browser support, your job will be much easier if you decide to use a Javascript library, such as jQuery. The big reason for this is because jQuery will encapsulate all of the difference between Javascript implementations between browsers. Writing this all from scratch is not really feasible.
So in your case, it sounds like you want users to select pictures and text, drag and drop them on a canvas of sorts. Then, what's your desired format for saving what they create? Are you trying to make a resulting image out of what they create?
To get started, I would check out jQuery UI. You can use the draggable and droppable functions for the front end, and when your users are done, you'll need to post the coordinates of their elements, text, and which pictures they're using, etc.
It seems like your biggest challenge is not making a pretty interface for this to happen, but instead, persisting what they create.

I've recently been working on something similar - you can check out the dev site here, and the js is not minified, so feel free to take what you want.
Initially I went for trying to 'render' the draft in SVG - this ended poorly, as browser support is still not that great, even using svg-web and similar libraries. I needed to do stuff like round text, and those features can really creep up on you.
In the end, I wrote a tiny python server (using CherryPy) that generates a png based on a set of querystring parameters using python-cairo. It takes serialized json object of 'text lines' and images. The png is actually the resource, and the function itself returns a 'render.png' filebuffer, so all you have to do on the front end is change the src attribute of the <img> tag and it will refresh. I added upload functionality to the "image processing" server, too.
Since I was already serializing json that contained all the information about the design, saving that in a database and loading it to edit designs was trivial.
I would definitely recommend a library like jQuery (which is what I used) to make development easier. I didn't manage to do much in the way of dragging/dropping, which is something I would probably try to do from the start if I was starting over. Feel free to email me if you'd like to see some of the back-end code or if you have any questions (my email is in my SO profile).

Jquery UI is the way to go, it provides drag and srop functionality and it's cross browser. Check it examples and documentations at http://jqueryui.com/demos/draggable/

How should I write a Jquery Mobile app for browsers with and without javascript support?

I'm trying to wrap my head around jQuery Mobile. My aim is to build a very fast application with a look and feel as close as possible to a native app (at least for modern devices).
I understand there are two ways of navigating between pages:
Loading each page as a separate page and linking to other pages with regular html anchors.
Putting all (or many) pages on one single web page and navigating between them by means of javascript ($.mobile.changePage (method) and similar api functions.
The first approach should work on all browsers, but performs quite poorly since there is a delay between each page transition.
The second looks like it should be much faster, so I would definitely prefer this approach. But how would that work for mobile device browsers without javascript support? It certainly seems to violate jQuery Mobile's aim to provide a gracefully degraded experience for C-grade browsers.
It looks to me like I need to implement my app twice, once optimized for browsers with javascript support, once for browsers without? Using may be another option, but that looks even more messy.
What's the recommended way to approach this dilemma? Is there anything I have not noticed?
Thanks,
Adrian

First of all: Your point2 is wrong.
See Local, internal linked "pages" in here and read it carefully. A link href="#pageelementid" will work just fine AND will work in any HTML4 capable browser too [might require <a name="pageelementid"> in some cases, I'm not sure anymore] with the only difference being that all the pages are visible at once.
Second thing is that if you use the way number 1 it will look quite nice too. It will load, yes, but in javascript-enabled browsers it's loaded with AJAX and there's no nasty blink between pages. Also - a "loading" popup shows up.
jQuery Mobile is supposed to let you create an application with some pure and simple html without any JS. JQM itself takes on the enhancement of the page so that it looks good and uses AJAX. Try to create an application that would work in every browser possible (my inspiration: lynx) and use JQM markup for that. Any javascript you are willing to write should work as an enhancement - making it better instead of making it work at all.
good luck with that!

The current thinking on supporting lesser browsers is to not degrade gracefully, but to enhance. If you build the website from the ground up to work without javascript then enhance it afterwards, then you pretty much know that the site will work (rather than having to fix it or build a secondary site).
As regards the two options you've specified, number one would be my preference as a mobile user if I had a limited bandwidth and also a lot of people have a restricted download amount per month.
Lumping all the pages into one large file may seem like a good idea (downloaded already), but you may well run into memory limitations on certain phones. And what if all they want to do is visit two pages, why should they be forced to download the entire website to do so?

Is it possible to optimize/shrink images before uploading?

I am working on a web application that will deal with many image uploads. Its quite likely that the users will be in areas with slow internet connections and I'm hoping to save them upload time by compressing the images before uploading.
I have seen that Aurigma Image Uploader achieves this using a java applet or active x but it's expensive and I'd rather something open source or at least a little cheaper. Ideally I'd like to roll my own if its at all possible.
I'm developing on Ruby on Rails if that makes any difference..
Thanks!
Edit just to clarify: I don't mind if the solution uses activeX or an applet (although js is ideal) - I'm just looking for something a little cheaper than Aurigma at this stage of development.
Also, it may not be feasible for users to shrink the image themselves as in many instances they will uploading directly from an internet cafe or other public internet spot.

Generally, it isn't possible to write an image compressor in JavaScript. Sorry.
You'll need to use a plugin of some sort, and as you mention, other sites use Java.
It appears to be possible to write something to encode a JPEG in ActionScript (i.e. Flash), which will reach a much larger audience than the Java plugin you mention. Here's a link to a blog post talking about PNG & JPEG encoders in ActionScript.
Here's another blog post with a demo of an inlined JPEG encoder in ActionScript.

Only if you use Flash or Silverlight (only way to be cross-platform)
http://www.jeff.wilcox.name/2008/07/fjcore-source/ may be worth a read.

Without using applets or activex (only in windows) you can't execute anything on a client pc.

Probably not, but you can always insist that image uploads over x size will not succeed.

Is this an application where you can force them to insert a smaller image. In that case you could grab the size first to verify it fits standards. This is what facebook used to do with profile pictures. If it was too big they wouldn't take it.