views:

125

answers:

6

With the increasing popularity of powerful client side javascript widgets, I am curious on when is the best time to handle the sorting of data strictly on the client side, making use of widgets such as those found in YUI, and when to make a request to the backend and have it handle the sorting via a DB query or other means.

+2  A: 

It depends on the amount of data - the best thing to do is to test and see which is faster.

Andrew Hare
+1  A: 

It really depends what you're sorting, whether the client will require all of the data or only a sorted subset at any one time, and how expensive the sort actually is.

Andrew Grant
A: 

Personally, I would probably sort it on a postback. But if all your data is displayed on the page, then sorting via JS might provide a more responsive UI.

John MacIntyre
A: 

You can do it all on the server, but it can be a strain, and your users risk long periods of waiting for their turn at the data.

It is quicker, for instance, to insert a row in its 'sorted' position in an existing table, than it is to draw the whole table again for an update.

It depends on how much of the data has changed. I'd say that if half of it is new, serve it up sorted, otherwise, sort the update in place.

kennebec
A: 

Another thing to think about is if you want to do a grouped sort or sort by a value and then translate that value into something human readable (ie unixtime), then it might be quicker and simpler to sort on the server.

Ólafur Waage
A: 

Except for exceptional cases, sort in the browser. Exceptional cases would be irrationally long lists, strange sorting rules requiring a host resource, insufficient javascript coding skills, etc. But there's not much to be gained from unnecessary round-tripping.

Very seldom does it make sense to download to the user more data than can comfortably be scrolled; and lists of this size should sort quite comfortably in the browser.

le dorfier