ha, I would wager that there is a simpler reason: sortable tables in HTML are nearly impossible to implement.
once you have a lot of data, you want fixed column headers. stacked sorting (column A first, then B), a lot of things suddenly become needed additions.
and where do you sort? front end or back end? how much data are processing?
just look at google spreadsheets and you'll see how sub-optimal it is.
sortable tables in HTML are nearly impossible to implement.
This is definitely a solvable (and solved) problem.
and where do you sort? front end or back end? how much data are processing?
If you have all the data loaded clientside, sort it there. Otherwise, just make a call to the server to query for data compliant with the new sort order. Both methods are fairly low cost.
I'm confused as to why this is hard. I code primarily in java with JSF for views and this is possibly the simplest thing to do in any of my projects. Using something like primefaces I generally never even need to write a line of javascript unless i need to customize some action and I can use theme roller / stock css for appearance.
This is working client side, if i want to do server side its as simple as implementing a single class that pushes the sorting/filtering/paging off the to the database:
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.
If you can push all your data to the front-end all at once, yes. DataTables makes this pretty straightforward.
Otherwise, his point stands. DataTables has hooks for this stuff, of course, but that's just a way of saying "DataTables doesn't itself solve this problem".
I rather like the fact that DataTables doesn't try and solve the whole problem (front end and server back end) - otherwise you end up with things like ASP.Net server controls and DataGrids which are really just an attempt to port desktop development approaches to the web - creating an unpleasantly leaky abstraction along the way.
I find that using DataTables as front end and hooking it up to a backend is pretty straightforward and results in a nice separation of concerns - let the server/database worry about paging, sorting, searching and filtering. Of course, if you have a relatively small amount of rows then just let DataTables do all the work - but at least you have the choice.
> If you can push all your data to the front-end all at once, yes. DataTables makes this pretty straightforward.
Paginagtion(ajax or page reload takes care of it). I use slickgrid https://github.com/mleibman/SlickGrid; pagination is straight forward, filtering takes some work. But do the hook once, and wrap the table in jquery-ui css framework's ui-widget, and you have a good looking, working table.
> but that's just a way of saying "DataTables doesn't itself solve this problem".
slickgrid is sortable, but filtering needs work. In fact, "slickgrid doesn't do everything" is part of its philosophy.
I have come to opposite conclusion that of author's. Having an excel sheet replacement in your repertoire is important, especially when you are replacing enterprisy stuff.
I found DataTables was much, much faster when I passed a JSON data hash - I think the DOM manipulation is what normally kills it. We've got some tables of several thousand rows in a small internal app and performance is fine, even in older IEs. (I think I tested up to several tens of thousands before IE started to be unreasonably slow - YMMV, of course.)
just look at google spreadsheets and you'll see how sub-optimal it is.
How is it sub-optimal?
One of my jobs is to make a UI that gets this right, so I'd appreciate hearing what you (or anybody) find deficient in the way online spreadsheets do this.
excel is the reference. it is so ridiculously optimized, it is not even funny.
outside of spreadsheets, take the itunes simple list view as a baseline. the 'simple' things are important. double-clicking the column border resizes the column to fit the longest text, etc.
once you have a lot of data, you want fixed column headers. stacked sorting (column A first, then B), a lot of things suddenly become needed additions.
and where do you sort? front end or back end? how much data are processing?
just look at google spreadsheets and you'll see how sub-optimal it is.