Beware the temptation of datagrids as the main UI element of your app.
It's very tempting: clients love datagrids because they know how to use them. You might like them because they're simple to plug in and provide tons of functionality you don't want to hand-code.
Multiple times have we implemented datagrids as the main UI of an application only to regret it later. Clients expect it to do everything Excel does, and are frustrated when that's not the case. Or they want to sort on a column that makes no sense to have in the datagrid, but if it's not in the grid you can't sort by it. And some of the implementations can be a nightmare to maintain beyond the common cases -- looking at you, ExtJS Grid.
More often than not, you can write a UI that serves the customers needs better and still meets their usability goals. And if they want to report on their data, allow them to download a daily dump in CSV format. Then they can do their Excel reporting without introducing a datagrid into the app.
I love Google's Spreadsheet. I know there's API to dynamically create and read/write spreadsheets. If there was a way to embed their spreadsheet in an existing page while still keeping it editable (not just an html output widget) then it would surpass every solution mentioned in this article. It allows copy-pasting, read/write XLS files, mouse-selection, formulas, and filtering.
If you're writing a web-app, you can relatively easily create a new spreadsheet-per-account on the fly, set it up with the right-structure, and just let the user do whatever they want. Periodically you can check the format/content and tell the user if something is invalid (missing column header, missing row data etc.) When everything is ok, the user hits save and you grab all the data from Google using their API. The best part is that each Google Spreadsheet comes with history so if a user doesn't screw something up, they can revert to an older version that worked instantly. Of course, you have to write your code to handle such features.
Be aware that since all of these are very Javascript heavy, their performance will depend a lot on the browser you use. For eg YUI data grids lets you reorder columns by drag and drop - try that in IE 8 and you will see what I mean. Off the ones in this list that I have tried, SlickGrid comes head and shoulders above others when it comes to performance.
Thank You HN. This is the first time, i've read about a working free JS DataGrid. Until now, I had to build those in ActionScript. It'd be nice to drop Flash from my projects.
Has anyone gathered some experience with both (JS + Flash DataGrids) and could tell me how they differ in performance (average load time, memory usage), compatibility (like browser-versions) and stability ?
(Most interestingly: Huge loads of Data. Flash gets slow, but doesn't crash. Google Spreadsheet for example, does)
It's very tempting: clients love datagrids because they know how to use them. You might like them because they're simple to plug in and provide tons of functionality you don't want to hand-code.
Multiple times have we implemented datagrids as the main UI of an application only to regret it later. Clients expect it to do everything Excel does, and are frustrated when that's not the case. Or they want to sort on a column that makes no sense to have in the datagrid, but if it's not in the grid you can't sort by it. And some of the implementations can be a nightmare to maintain beyond the common cases -- looking at you, ExtJS Grid.
More often than not, you can write a UI that serves the customers needs better and still meets their usability goals. And if they want to report on their data, allow them to download a daily dump in CSV format. Then they can do their Excel reporting without introducing a datagrid into the app.