SlickGrid Evaluation

Posted on by

SlickGrid Links

- Home: https://github.com/mleibman/SlickGrid/wiki
- Examples: https://github.com/mleibman/SlickGrid/wiki/Examples
- AJAX paging: http://mleibman.github.com/SlickGrid/examples/example6-ajax-loading.html
- Used By: https://github.com/mleibman/SlickGrid/wiki/Used-by

NOTE

A full evaluation of this product was not performed. Although I spent as much time in the evaluation as the other tables, I determined that SlickGrid is no longer a candidate for our use.

Here’s what I learned:

1) SlickGrid is primarily designed around the “paging via scroll bar” mechanism. Actually, to be even more precise, it’s really “rendering via scroll bar”. SlickGrid primarily attempts to load all records into JavaScript, then defers rendering of those records until they’re scrolled into view.

2) SlickGrid does have a remote paging capability as seen in Example 6. However, almost all of its examples, and most of its add-ons, are geared around the concept that everything’s already loaded into Javascript variables. When using server-side paging, it does offload the filtering and sorting to the server.

3) Example 4, the Grouping Example, and the Optimized DataView Example show a paging navigator control (enabled via the small icon at bottom-right). However, examples do not exist for server-side paged data.

  • The current Slick.Controls.Pager widget (which produces the nav bar) was intended for use with the DataView class. The DataView class, in turn, was designed to work with fully-loaded data. Hence, the navigation bar cannot at this time be used with AJAX- loaded data. There are people who have gotten it to work with various hacks, but this is not yet part of this library.

4) SlickGrid does NOT use <table><tr><td> codes. Instead, it uses a series of div’s
5) SlickGrid is not as mature, well supported, or well documented as jqGrid or DataTables

============================================================

Evaluation

In order to properly evaluate jqGrid, DataTables, and SlickGrid against our “good enough” criteria, I set up a test REST server that returns “real” JSON data. The server contains a list of over 10,000 objects.

While the data is real, the response time is not. The test REST server pre-fetches all real data from back-end services, then cache’s that data internally in order to eliminate server response time in the evaluation. While real server calls are measured in 10ths of seconds, my test REST server’s average response time is 3ms for any given page of 50 objects.

I had to create unique REST end-points for each of my tables in this evaluation because each uses different parameters to control the list behavior. They all pull from the same list of cached objects.

I created a test html file — /SlickGrid/slickgrid.html — which creates a SlickGrid table and loads Users (50 at a time from a set of 10,000) from a SlickGrid-specific REST end-point.

1) Performance is #1

  • performance of fetching remote data is outstanding …just like the other table controls
  • 50 records: desktop, round-trip is 3ms, iPad3 it’s about .3s – .5s
  • 500 records:
  • SlickGrid implements Virtual Rendering preventing the drawing of a given row until it is scrolled into view
  • SlickGrid is capable of post-rendering work. For example, filling a given cell with a value from the server even after the row’s been scrolled into view. Here’s an example. Post-rendering takes place only when the UI is idle. Rows are processed 1-by-1.

2) Device requirements: performance and functionality will be determined by ICS-based tablets, not older Honeycomb devices, not smart phones

  • As noted above, performance on an iPad3 is outstanding

3) Table paging and navigation will be performed by next, prev, first, last, and #’s links

  • SlickGrid does not provide a navigation control for ajax-loaded data since it is primarily a page-via-scrollbar solution
  • Turns out the current Slick.Controls.Pager widget (which produces the nav bar) was intended for use with the DataView class. The DataView class, in turn, was designed to work with fully-loaded data. Hence, the navigation bar cannot at this time be used with AJAX-loaded data. There are people who have gotten it to work with various hacks, but this is not yet part of this library.

4) The table will load 1 “page” of data at a time, if the rows don’t “fit” the vertical table size, users may scroll to see the rest of the page

  • SlickGrid’s loads 1 “page” of data at a time. Previously loaded data is cached.
  • However, it does not provide a navigation control. Hence, the only pagination is via the scroll bar.
  • If the fetched rows don’t “fit” the vertical table size, users may scroll to see the rest of the page
  • The table can be sized such that it grows as needed to accommodate all rows

5) The table will not cache previous requests (to protect mobile devices; and if #1 is met, no need)

  • SlickGrid by default CACHE’s previous requests
  • Uncertain if this can be turned off

6) All paging, filtering, sorting will be performed by the back-end; none in the client

  • SlickGrid can be set up to paging, filtering, and sorting in both the UI and the back-end
  • However, SlickGrid’s DataView (required for using the navigation widget) is only available for fully-loaded data (not AJAX data)
  • When loading AJAX data, SlickGrid performs paging, filtering, and sorting by the back-end

7) We will filter on only string data originating from the server for now

  • Unexamined

8) Code size should not exceed 200K (minified and gzip’d); the smaller the better

  • Unexamined

9) We will only select a mature, well supported Table widget. We will not make our own.

  • Current version: 2.0.1, actively developed
  • This product does not appear to be as mature, as well supported, or as well documented as jqGrid or DataTables

10) Theming Support :

  • Unexamined

11) Table must by stylable as in our mockups

  • Unexamined
  • Every cell can be given a specific style name. Hence, I believe the table is stylable
  • SlickGrid is able to use John Resig’s micro-templates while still using SlickGrid’s virtual rendering technology

12) Single select for Marketplace; likely multi-select for future

  • SlickGrid supports single selection via row-selection or checkboxes
  • multi-select with checkboxes …but mostly unexamined

13) In-row actions for Marketplace; likely top-of list actions for future

  • SlickGrid supports any buttons we’d like to place in a row
  • SlickGrid is capable of post-rendering work. For example, filling a given cell with a value from the server even after the row’s been scrolled into view. Here’s an example. Post-rendering takes place only when the UI is idle. Rows are processed 1-by-1.

14) No in-cell editing for now

  • SlickGrid does support in-cell editing, however this can easily be turned off

15) No “View As…” alternate views for now

  • SlickGrid does not directly support alternate views for its tables

16) No conclusion on table width handling. However, the survey says most people would like to see columns shrink until it’s ridiculous, then hide low-priority columns altogether

  • Columns can be fixed or proportionally sized
  • Data within the cells shows ellipses if cell contents exceed cell size

17) The table needs to support a distribution-friendly license

  • SlickGrid is licensed under the MIT

Leave a Reply