ajax requests vs. dom/browser efficiency? who wins?

I have an app that employs a scrollable jQuery carousel type display. This display contains photos开发者_如何学Python that belong to a user... Each photo has a considerable amount of sibling html content (data pertaining to the photo that displays when you hover over it, etc)-- So this markup, plus the image tag is all nested within a container element with a css class "photo"..

To further complicate things, each photo is draggable, and has several other behaviors/event listeners attached to it.

When I was initially designing this, I felt worried about this carousel being loaded with too much data (like imagine a user that has 10000 photos).. I was quickly imagining the dom being overloaded with too many elements, and everything being draggable, and then spinning color balls of death followed by a crash.

My solution to this was to limit the load of the carousel through pagination, and only fetch the assets for a given page... This means there will be a considerable amounts of xhr requests for a given user browsing their photos..... And that concerned me also.

So I am wondering what the community says... What is better? an overloaded dom? or many xhr requests? Or is the answer maybe more of a balance between the two?

Opinions?

Use ajax, only load x at a time until the user scrolls further through the carousel, then load x more.

Many XHR requests is the way to go. IE especially doesn't like cluttered DOMs. It handles static display fine, but then if you try to animate with jQuery you'll get really choppy ugly results.

I would define some client side templates with something like http://api.jquery.com/jQuery.template/ and pass back JSON metadata for your picture. That way your network traffic is minimal. So load like 5-10 to start and then buffer in 10 at a time. Delete the start of the carousel when you get up to 100 or so. You can then play with those "magic numbers" based on how it performs in IE < 9 (the other browsers should be fine).

Personally, whenever I am dealing with something like this, I look at what browser I am developing for.

If it's for a client, or something you are selling to a specific set of people, and you can kind of "control" the environment which you officially support, figure out what that is, and make the best decision for the browser. For example, Internet Explorer (pre IE9), gets bogged down with a lot of AJAX requests, and you would probably benefit from just masking some sort of loading bar over top of the page while filling the DOM with elements.

Firefox however, doesn't have any sort of AJAX limitations as far as I know of, so I would always be for paging/making multiple AJAX calls there.

As a rule of thumb for myself though, I'd like to try and make AJAX work FIRST. That's usually the most efficient/easiest way to go right now, if you can. It's always better if it works.

I would lean towards a balance of the two. Maybe something along the lines of, on page load, load your initial set of photos AND preload the next set of photos in the background after the initial set is displayed (either JS or CSS method, I'm not sure which is more efficient), and on pagination, the preloaded set comes into view while you make an AJAX request to retrieve and build the next set of photos.

This way, everytime the user paginates, they won't have to wait for the server to respond to the AJAX request, but yet you won't end up with 10000 photos in the DOM either.