[ANTSANTS]

Yes. Asynchronous image loading and rendering is already built into the browser, and the rest of the content shouldn't take long to load to begin with. Fancy dynamic Javascript frameworks that break up what should have been a single response into 20 different responses, asynchronously firing dozens of superfluous repaints as the data trickles in, cause far worse performance, latency, and usability problems than rendering a single chunk of HTML ever did.

[nilliams]

Nobody says this has anything to do with 'Fancy dynamic Javascript frameworks that break up what should have been a single response into 20 different responses, asynchronously firing dozens of superfluous repaints ...'

The use-case for this type of solution can occur in a relatively simple app (web app or native), with a master/detail layout when the user loads the 'detail' view for an item (and it has to fetch network data).

I'm looking at my desktop Spotify app and seeing places where this approach is applicable. Of course it loads so fast to me it seems unnecessary, but that will not be the case for everyone in the world.

[alextgordon]

> The use-case for this type of solution can occur in a relatively simple app (web app or native), with a master/detail layout when the user loads the 'detail' view for an item (and it has to fetch network data).

Would probably be better to spend developer time on more aggressive preloading then.

If there are 30 items visible in the master view, and each is 1 kB of JSON, then just load the 30k of JSON in the background (after a delay, of course).

[nilliams]

> Would probably be better to spend developer time on more aggressive preloading then.

That should be considered regardless, it's not an either-or situation.

> If there are 30 items visible in the master view, and each is 1 kB of JSON, then just load the 30k of JSON in the background (after a delay, of course).

I said simple app, not completely trivial app! :)