JSF is a bit of exception. I haven't 'really' searched but its harder to do this in say Struts. What rule of thumb for the data size do you use when choosing between client side and server side sorting?
I wouldn't say there is a hard rule of thumb and there are three levels of operation possible, at least with primefaces:
1) All row data sent to client side, all paging done on client
2) Backing controller contains a List with all data in memory, client only gets 1 page at a time via ajax updates.
3) A truly 'Lazy' data model, ajax request for a new page of rows, controller references a lazy data model that fetches just that page worth of data from the database tier and sends it to the client.
In practice I really only use #2 and #3 normally. Unless the application has a bad internet connection as a requirement I assume its faster or negligible to fetch pages via ajax vs loading them all into the client up front. As far as choosing between #2 and #3, for my applications its usually obvious, the table either contains 5-25 items (go with 2) or thousands of items (go with 3).
In the middle ground i guess it comes down to loading: Can you afford to use more memory in the web tier or would you rather keep that memory usage down and suffer slightly long update times? Assuming your database is well designed it should only had maybe 10ms onto your response time to just grab the page from the database vs already having it in memory.
