3 ms·

> .ajax = iframes I was pretty much in the same boat as you regarding all the other choices, but when i saw this I thought: "Seriously?" I remember when AJAX

> .ajax = iframes I was pretty much in the same boat as you regarding all the other choices, but when i saw this I thought: "Seriously?" 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?

nostrademons 13y ago
Iframes have a couple advantages over XHR: 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.
- derefr 13y ago
  Regarding the first objection, you could just send your responses as a series of websocket messages, rather than repeated AJAX request/response pairs. 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? :)
  - nostrademons 13y ago
    Yeah, websockets are fairly useful if your data is JSON blobs or other byte data, but awkward if you just want to ship some more HTML for display. They're best used in long-running client applications. 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.
    - derefr 13y ago
      > well, a modified version that gives better latency 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.

nostrademons 13y ago

Iframes have a couple advantages over XHR: 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.

derefr 13y ago
Regarding the first objection, you could just send your responses as a series of websocket messages, rather than repeated AJAX request/response pairs. 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? :)
- nostrademons 13y ago
  Yeah, websockets are fairly useful if your data is JSON blobs or other byte data, but awkward if you just want to ship some more HTML for display. They're best used in long-running client applications. 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.
  - derefr 13y ago
    > well, a modified version that gives better latency 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.