title: SlickGrid Vs JQGrid
body: <p>I am trying to decide between slickgrid and jqgrid. I think both of them are feature-rich. Jqgrid has great documentation, so its easy to get up &amp; running. </p>
  
  <p>I am trying to understand, how different they are, in terms of implementation details since I heard slick grid is lot faster. I was just wondering if anyone did some benchmarking / know the internals of  each grid to provide some useful inputs.</p>
  
  <p><strong>Edit1:</strong> @oleg - Thanks for your response. Sorry, I was afraid that I might not have provided enough details. Although I do not have all the use-cases, but I will be using both the local data when data is small and server-side virtual scrolling, filtering, sorting etc. when data is large. Json will be the primary datasoure. I was trying to get inputs from someone who might understand the internals of both grids. I do not understand the client-side implementation enough to judge those myself. One of my colleague's mentioned that slick grid might be better since it  was developed with virtual rendering and key-board support to being with. My question is open ended but the core-implementation of the grid might make it efficient in the more complex scenarios too i.e. sub-grids, trees etc. if there is no departure from the core design to handle any of those. </p>
  
  <p><strong>Ok, based on ur expertise of jqgrid, how would you respond to this snippet from <a href="https://github.com/mleibman/SlickGrid/wiki">Slick Grid</a> ?</strong>  </p>
  
  <p>"<em>Grid vs Data
  The key difference is between SlickGrid and other grid implementation I have seen is that they focus too much on being able to understand and work with data (search, sort, parse, ajax load, etc.) and not enough on being a better “grid” (or, in case of editable grids, a spreadsheet). It’s great if all you want to do is “spruce up” an HTML TABLE or slap a front end onto a simple list, but too inflexible for anything else.
  Data is complicated. It has business rules. It has non-intrinsic properties. Editing one property of an element can lead to cascading changes modifying other properties or even other elements. It has dependencies. What I’m saying, is that dealing with data is best left to the developer using the grid control. Trying to fit all of that into the grid implementation and API will only limit its applicability and add considerable bloat.
  SlickGrid takes a different approach. In the simplest scenario, it accesses data through an array interface (i.e. using “dataitem” to get to an item at a given position and “data.length” to determine the number of items), but the API is structured in such a way that it is very easy to make the grid react to any possible changes to the underlying data.</em>"</p>
  
  <p><strong>Edit 2:</strong> Snippet from <a href="http://www.datatables.net/forums/discussion/3834/virtual-rendering-for-massive-speed-and-scalability/p1">Datatables forum post</a> : "*DataTables <em>is</em> trying to spruce up an HTML table. This can be seen, for example, by the use of the TABLE tag by DataTables, while SlickGrid uses DIV elements to create a display which looks like a table. As such, there are a number of techniques, like the virtual rendering, which can be used <strong>with the DIVs - but not with a table</strong>. It's not possible to simply render rows 100-110 and not the first 100 in a table, but it's no problem with DIVs, so I'm afraid that this isn't applicable at the moment. What would need to be done is to convert DataTables to using a DIV tag markup, but then you loose the primary goal of DataTables, which is focus on progressive enhancement and accessibility.*"</p>
  
  <p>Thanks</p>