Don't optimize the code until you've optimized the algorithm

A co-worker pointed out an article regarding performance tuning for the JQuery DataTables this morning. The author goes through a lot of effort to improve the performance of a JQuery DataTable when adding 1000 rows. It's a valiant effort, and some good code is in there, but, there's a better way.

P. J. Plauger once wrote "Don't optimize the code until you've optimized the algorithm".

Truer words have not been spoken. I spent way too much time (a long time ago in a galaxy far far away) "optimizing" interrupt service routines into 8086 ASM code. I was convinced that a C compiler could not produce code that was as good as I could write - and I was correct. However, I was so caught up in being "right" that I was wrong. Sure, I could write better asm code than a C compiler, but, my asm code was doing the job all the "wrong" ways. My algorithm was flawed. I modified the algorithm, converted the asm code to C and the result was better performance (and a lot less bleeding).

This poor fellow above has fallen into that trap - he's trying to find a better way to stuff 1000 rows into the DOM. Don't waste time and effort trying to find a better way to stuff 1000 rows into the DOM - find a better way to NOT send 1000 rows to the browser! What's that better way you ask? Server side pagination, and it's built into DataTables:

Server-side pagination with DataTables

Certainly, there are situations where you need or want all the data at once, but those situations are typically rare. Think long and hard before you go loading 1000 records into your browser. Server side paging is almost always a win-win-win for viewing large datasets: less impact on the server, less bandwidth used (the data gets there faster) and the page load is faster, improving the user experience - especially on mobile devices.