As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
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
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.
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
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
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.
Related
I'm allowing users to select an icon from the full list of FontAwesome icons (using a List<ImageVector>). I'm going to open a dialog, and show the icons as IconButtons arranged in the list. There are ~1600 icons.
I implemented it using a LazyVerticalGrid, with a fixed number of columns. It works, but there's some lag loading the icons, and lag when scrolling the icons.
I'm converting this from a React Native project where I did the same thing (with a larger set of icons, actually) and scrolling that was pretty snappy, so I'm assuming it's possible to do performantly on native. Perhaps ImageVectors are heavier than the SVGs I was using in React Native?
I'm planning to provide a search box in the dialog where users can filter the list down by doing a fuzzy search on icon names, so the grid will change over time.
What sort of patterns should I be looking at here? Is LazyVerticalGrid the way to go, or should I be using a different approach entirely?
On Laziness
For an overview of use cases and appliable patterns you might be interested in the Android Dev Docs' page on Lists and Grids, încluding the topics Large data-sets (Paging) and the Tips on using Lazy layout.
This might wake your interest on the Android Jetpack Paging Library androidx.paging, which is designed for loading and displaying pages from large datasets, basically uniting the concepts of Laziness and Caching.
Currently you're only using Laziness. As Bartek Lipinski commented, that should usually be fine when the graphics to display are static. However, when they have to be loaded asynchronously, Paging will probably improve your performance.
Some Rules of Thumb
Scrolling
Pattern
No
Column or Row will be enough
Some
Column or Row with modifiers verticalScroll and horizontalScroll
More, static content
LazyColumn or LazyRow, resp. for gridding LazyVerticalGrid or LazyHorizontalGrid
More to mass, dynamic content
LazyColumn or one of its relatives with LazyPagingItems, so using the Paging Library androidx.paging
Also, as the docs say, consider adding contentType
. However, as Bartek Lipinski remarked, one usually benefits of contentType when there are scrollable elements of various types -- not only SVGs as maybe in your case. Still, giving hints to the system doesn't hurt, at least.
On Vector Graphics
As discussed in the comments, esp. by Subfly and Bartek Lipinski, though Laziness should be the main thing here, another bottleneck could be the loading of vector graphics during runtime.
If the graphics used are of static nature, then consider the usage of vector graphic assets. Those are supported for SVG and PSD since Android 5.0 (API level 21). Take also a look on the recommendations and some aspects of support and restrictions on SVG.
Summary
The basic formula is Laziness + Vector Assets with focus on the first. One might spice that with contentType and Paging.
I'm not sure StackOverflow is the best StackExchange site for this but I can't find a general standards/architecture one, if StackOverflow isn't the best place for a question in this form please point me in the correct direction.
I'm trying to find a universal UI format, due to business constraints I can't get too far into the specific use case, but am looking for something which would function as a minimal UI format for calling API functions, displaying tabular or descriptive data, ideally with images and other binary formats included, and displaying regardless of unforeseeable future changes in tech.
Is vanilla HTML the best solution here, or is there a more base-level option around already?
I'm in the need of an Excel like grid in an attempt to convert an "application" written in Google Calc to a real application. I've got one implementation using Vaadin, but it (also) suffers from a long page construction. The screenshot below uses a CSS flex grid with individual divs, and given 6 weeks, there are over 5000 individual divs.
Constructing this page takes over 20 seconds, not something users will be happy about. I'm working on a version based on a table, but it does not seem to improve much. In the end the same amount of cells need to be constructed, whether they are DIVs or TDs does not seem to matter much.
Is there a way to construct such a grid in a more speedy way? I'm more than happy to solve "where did the user click?" on the server side. To be aware of: besides the number of cells themselves, each also has specific content, so just getting a grid shown is not enough.
Each component (div, or something else) is managed by the server. So when you have 5000 of them it's quite slow. You need to reduce the number of components managed by the server.
I can't give you a better answer since I don't know the requirements. But the idea is to try to combine some elements.
You have an example of a table generated ( instead of each element one by one) here: https://cookbook.vaadin.com/grid-details-table.
You can also create or own component. There is also a paid add-on: spreadsheet which seems to fit your needs. It's still in preview: https://vaadin.com/roadmap
The problem here is the complexity of the UI itself. Rendering 5000+ cells will be slow what ever method you use and what ever framework you use. There will be big amount of elements in the DOM and you need to load also lot of data upfront. And as you see the result is huge, and it wont fit most screens. So I would recommend further design of the UI. Is it really necessary to show all the weeks at once? Your UI's complexity will already reduce a lot if you show only one week at the time and add buttons to browse the weeks forwards and backwards. But even with that optimization you will have lot of columns. I would consider adding another browsing direction by day. Further knowledge of the actual purpose of the UI will naturally give more insight how to develop it further.
I have a gwt list grid which i need to show more than 1000 messages.
But it takes 40millsec to display each message. So it is very slow.
Can u help me so that i can show all messages in less time.
Thanks Nagaraju
As Bogdan said paging is your best bet.
However if your requirement strictly needs you to have the 1000+ lines at one time I would reconsider the grid approach.
When you are working with such a large amount of elements an iterative dom "touch" will be dirt slow.
See if you can rather create a component that gets the messages into String form with their markup. Then set the inner HTML once. You can then use something like jquery or gwtquery to attach handlers to the elements in a timely fashion.
Failing that you could use a lazy render method where you render only whats on-screen but that gets much more complicated.
Answering this 2 Year old question Just for Kicks -
GWT has progressed a lot since 2 Years.
GWT provides hell lot of options to User to do performance tuning.
GWT as done a lot of perormance tuning on widgets. GWT 2.5 has Cell
Widgets like CellList/CellTable/DataGrid which make displaying large
data easier , faster and with light weight heavy DOM.
Reference -
https://developers.google.com/web-toolkit/doc/latest/DevGuideUiCellWidgets
Summary -
Cell widgets (data presentation widgets) are high-performance, lightweight widgets composed of Cells for displaying data. Examples are lists, tables, trees and browsers. These widgets are designed to handle and display very large sets of data quickly. A cell widget renders its user interface as an HTML string, using innerHTML instead of traditional DOM manipulation. This design follows the flyweight pattern where data is accessed and cached only as needed, and passed to flyweight Cell objects. A cell widget can accept data from any type of data source. The data model handles asynchronous updates as well as push updates. When you change the data, the view is automatically updated.
In addition, cells can override onBrowserEvent to act as a flyweight that handles events that are fired on elements that were rendered by the cell.
Note -
1) CellTable being capable of displaying large data also come with Pager options and also AutoPage on Scrolling option ( example CellList )
2) Also, if you come across any other performance issues in GWT you can call in the Bazooka features of GWT - SpeedTracer, Logging, Chrome Dev tools Profiling, GWT Light Weight Metrics, Code Splitting, GWT Compiler Metrics, GWT Closure Compiler, Resource Bundling to crush it !!!!
1000 items for a web-based application is too much. Try implementing some sort of paging algorithm. You could look at the PagingScrollTable from gwt incubator ;)
I've been working exclusively with ComponentArt controls and want to know what else is out there. What Grid and Treeview controls are worth investigating?
It doesn't matter if I need to pay for them... quality, speed, and reliability are key.
I've seen a few issues with the CA Grid Control has issues with setting the column width dynamically, and documentation is spotty. However it has a single programming model with the SOA offering. Are there better options out there?
Try dhtmlx Grid and dhtmlx TreeGrid , although these are javascript components we have used them with asp.net and find them to be very fast and flexible.
jqGrid is a nice AJAX-enabled grid written in JavaScript that has worked out well for me in several recent projects.
jQuery treeView looks like a bare-bones treeview that may be worth investigating, although I have not used it on any projects so your mileage may vary.
I use the Telerik's AJAX/Silverlight grids for my web apps and I am pretty content with them. The components are flexible and designed with the idea of rich set of features without compromising the overall performance. If you want to have a look at their online examples, go here.
Dick