views:

1114

answers:

8

What is it best to handle pagination? Server side or doing it dynamically using javascript?

I'm working on a project which is heavy on the ajax and pulling in data dynamically, so I've been working on a javascript pagination system that uses the dom - but I'm starting to think it would be better to handle it all server side.

What are everyone's thoughts?

+5  A: 

Doing it on client side will make your user download all the data at first which might not be needed, and will remove the primary benefit of pagination.

The best way to do so for such kind of AJAX apps is to make AJAX call the server for next page and add update the current page using client side script.

Mehrdad Afshari
+1  A: 

Server side - send to the client just enough content for the current view.

Otávio Décio
+16  A: 

The right answer depends on your priorities and the size of the data set to be paginated.

Server side pagination is best for:

  • Large data set
  • Faster initial page load
  • Accessibility for those not running javascript

Client side pagination is best for:

  • Small data set
  • Faster subsequent page loads

So if you're paginating for primarily cosmetic reasons, it makes more sense to handle it client side. And if you're paginating to reduce initial load time, server side is the obvious choice.

Of course, client side's advantage on subsequent page load times diminishes if you utilize Ajax to load subsequent pages.

Cory House
+4  A: 

If you have large pages and a large number of pages you are better of requesting pages in chunks from the server via AJAX. So let the server do the pagination, based of your request URL.

You can also pre-fetch the next few pages the user will likely view to make the interface seem more responsive.

If there are only few pages, grabbing it all up-front and paginating on the client may be a better choice.

Diodeus
+1  A: 

Even with small data sizes the best choice would be server side pagination. You will not have to worry later if your web application scales further.

And for larger data sizes the answer is obvious.

A: 

In a practical world of limits, I would page on the server side to conserve all the resources associated with sending the data. Also, the server needs to protect itself from a malicious/malfunctioning client asking for a HUGE page.

Once that code is happily chugging along, I would add "smarts" to the client to get the "next" and "previous" page and hold that in memory. When the user pages to the next page, update your cache.

If the client software does this sort of page caching, do consider how fast your data ages (is likely to change) and if you should check that your cached page of data is still valid. Maybe re-request it if it ages more than 2 minutes. Maybe have a "dirty" flag in it. Something like that. Hope you find this helpful. :)

sam
+1  A: 

I prefer server side pagination. However, when implementing it, you need to make sure that you're optimizing your SQL properly. For instance, I believe in MySQL, if you use the LIMIT option it doesn't use the index so you need to rewrite your sql to use the index properly.

G-Man

GeoffreyF67
+1  A: 

Do you mean that your JavaScript has all the data in memory, and shows one page a time? Or that it downloads each page from the server as it's needed, using AJAX?

If it's the latter, you also may need to think about sorting. If you sort using JavaScript, you'll only be able to sort one page at a time, which doesn't make much sense. So your sorting should be done on the server.

JW