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.)