SlickGrid Vs JQGrid [closed]

问题:

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 & running.

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.

Edit1: @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.

Ok, based on ur expertise of jqgrid, how would you respond to this snippet from Slick Grid ?

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

Edit 2: Snippet from Datatables forum post : "*DataTables is 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 with the DIVs - but not with a table. 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.*"

Thanks

回答1:

I looked at jqGrid and SlickGrid and found that SlickGrid is much more elegantly written; less configuration is needed for most use-cases for SlickGrid; jqGrid, however, need less configuration to set up the more complex cases (such as virtual scrolling);

jqGrid might have better documentation but the server-side connection part for jqGrid is covered by a commercial offering and documentation on this part is more difficult to obtain than for the client-side.

SlickGrid, on the other hand, have some great examples which covers most use-cases and the source is full of comments and is accessible to anyone with some intermediate knowledge of javascript and jquery.

回答2:

Having used both jqGrid & slickgrid in production/anger, here are my 2 cents: jqGrid was very easy to get started with and hook in. However we quickly found ourselves grating against having to fit what we wanted into jqGrids way of doing things. We also found the editing capabilities difficult to implement and (from memory - this was a year ago) it forced you into a row edit model, rather than cell edit which did not perform well.

With slick grid we have yet to hit a feature that was missing / we could not easily plugin. The documentation was fairly non-existent but is now much better (https://github.com/mleibman/SlickGrid/wiki/_pages) but to date we've just been jumping into the source. Have to say the api is one of the best I've seen, and performance with large data volumes and complex editors has been excellent (some issues on ie7 but never isolated that to the grid vs our MVC framework & complex editors)

All in all, I'd highly recommend slick grid

回答3:

Which language is more difficult to study: Chinese, Finnish or the language of some small Indiana folk?

The comparing questions are always too difficult. You have to have people who really good knows all the products which you want to compare. Moreover you should define which part of the product you plan to use just now and which could be important in the future. Do you use JSON or XML data for the grid input or you use local JavaScript data? Do you need to use standard grid or grid with subgrids, treegrid or a grid with grouping?

Before you not define the area of the usage of the grid more clear you will not receive any good answer. At the end is sometime could be even important which know-how you have currently and just which documentation or examples you can easy understand and use yourself. The experience of other people which you can use could be more important as the features of the product. If you look at the number of questions on the stackoverflow.com with the tags "jqgrid" and with the tag "slickgrid" you can see in what product could help you stackoverflow

回答4:

I agree with @user175528. We've used the grid extensively in our application too and its built in formatters, editors and validators are really easy to use and its easy to write custom ones as well.

It handles large datasets well (and makes searching through them a breeze). Additionally, its easy to setup paging and sorting.

Initially when I started using the slickgrid, I had wrapped it in another widget so that I could move to another provider if need be, but as of now, it seems to work flawlessly.

I haven't gotten around to it yet, but I will be posing some good slickgrid examples on my blog.