> .ajax = iframes
I remember when AJAX came out: I was finishing my iframe-based custom-rolled 'AJAX'. It was such a hack, I can't even believe someone would consider it in 2013.
Why not XMLHttpRequest?
1. You can do progressive rendering with an iframe. With an XHR you don't get the 'loaded' callback until the entire response has arrived, and so you can't start working with and manipulating the data until it's all there. With an iframe you can put successive chunks in <script> tags and they will start executing as soon as the closing tag for the script is found. Or if you want to transport the data as HTML, you can put a 0-length animation on each element that forms a response chunk, and listen for the animationend event to get notified as soon as it's ready in the DOM.
2. You can measure and manipulate elements while they're still in the iframe. For example, if you're animating the rest of your layout, you can measure the size of the elements that you just loaded inside a hidden iframe, adjust transitions on the main page to make space for them, and then pop the elements from the iframe into their proper places in the final layout. With an XHR, the only way to measure the element is to place it into the DOM and force a layout, which is much slower, particularly on mobile devices.
3. Iframes form a layout boundary, so when the browser lays out elements in them it stops the layout process at the iframe. This eliminates the need to do a CPU-intensive layout of the whole page when you pop in your XHR content.
The other two objections I'm not so clear on--maybe because I don't often dynamically construct views by retrieving "presentation" from the server. In what I've seen as "idiomatic HTML5 client-side development", all the views are shipped as templates with the initial code-blob that starts up the client; from then on, the client just speaks pure data-related JSON to the backend's plain HTML-unaware API. Does this practice not scale to Google levels? :)
As for sending JSON with rich clients vs. rendering HTML on the server; that depends a lot on the intended usage pattern of the app. For apps that you expect will be open for hours at a time, like e-mail or social networking, the former pattern is better - and indeed, GMail and G+ both speak JSON (well, a modified version that gives better latency) to rich client JS. For apps that you open quickly, perform your task, and then close (Search is the canonical example), it's far better to render all your HTML on the server and just ship that down to the browser. There is a large cost to downloading and executing all that JS, and you lose many, many customers if your app is slow.
There are strategic reasons why, if I were founding a startup today, I'd prefer to play in markets where the latter case held, unless I was writing enterprise software. Consumer markets where people spend hours with an app open are rare, and Google/Facebook generally want to own that space. I would rather not compete with them. On mobile, the open-for-hours apps are generally moving to native, where you can interact with the platform's notification API. The sweet spot for long-running webapps is enterprise and intranet applications, which has many fruitful markets, but many technologists shy away from it because there are frequently many arbitrary and difficult requirements.
Any more details on this (that you're allowed to talk about)? Low-latency JSON-alike communication is something I'd be highly interested in.
Personally, I've investigated BERT.js for this use-case, but it didn't work quite right (likely since the available client library was written to construct binary messages using String.charCodeAt, rather than just writing directly to an ArrayBuffer.) I kind of gave up when I realized I might be--especially on mobile--spending long enough on the pure-JS encoding/decoding processes (versus the browser's native JSON implementation) to lose any gains I'd get from the network. If you know otherwise, I'd like to hear about it.