Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: React-data sheet, Excel-like spreadsheet component

nadbm.github.io

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#71

Post by csours »

josephcooney wrote: post #69
csours wrote: post #67

Anytime I see something that looks like Excel on the web, I cringe. Unless you are Microsoft or Google and you are putting spreadsheets on a website (SoW), you are almost certainly doing something wrong. --- Case 1: A co-worker (or yourself) previously wrote an excel-based app and now it's time to put it on the web for wider distribution. You implement the app with a custom gridview/spreadsheet. Error in Case 1: The…

Agree. Here is a rant from me expressing the same sentiment from a while ago https://jcooney.net/post/2008/06/08/Data-grids-lack-of-imagi...

Yup, you see a very similar pattern with prototype or MVP code.

People get fixated on the code or UI in front of them and they don't think about the actual use cases.

http://www.snopes.com/weddings/newlywed/secret.asp

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#72

Post by csours »

david927 wrote: post #68
csours wrote: post #67

Anytime I see something that looks like Excel on the web, I cringe. Unless you are Microsoft or Google and you are putting spreadsheets on a website (SoW), you are almost certainly doing something wrong. --- Case 1: A co-worker (or yourself) previously wrote an excel-based app and now it's time to put it on the web for wider distribution. You implement the app with a custom gridview/spreadsheet. Error in Case 1: The…

Error in Case 4: There is no error here, only madness. Then give me madness. The problem is that spreadsheets are one of the most natural interfaces for data that we humans have, and even with Microsoft and Google's efforts included, current spreadsheets on a website (SoW) suck. So let's say the y-axis is importance of function and the x-axis is compelling implementation --> voila! Right there, plotted on the graph y…

> spreadsheets are one of the most natural interfaces for data that we humans have

Spreadsheets are natural for data, but not for humans. Spreadsheets are excellent for prototyping and data munging; and spreadsheet prototype apps are even fine for personal or small team use.

When you get medium team size or multiple small teams that spreadsheets break down.

Part of that breakdown is in distribution - which SoW solves.

But another part of that breakdown is in not understanding the implicit rules of the spreadsheet app - another team or person will put some garbage in a cell and break the 'app'.

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#73

Post by TheAceOfHearts »

georgewfraser wrote: post #32

I have spent way too much time building grid components at my company, and I've found that if you have (1) a lot of data, (2) a dense grid, and (3) a grid that occupies most of the screen, THEN the only way to get 30+fps is to use canvas and do all the layout and drawing logic yourself.

Have you tried out react-virtualized [0]? The author has invested a ton of time tweaking things left and right in order to get optimal performance. It's by far the best virtualized grid in JS that I've had the pleasure of using. In addition to that, the React Fiber rewrite should eventually introduce a few new APIs which, as I understand it, should enable further performance improvements. If you scroll really fast it'll flicker white and rendering will lag behind a bit, but it won't cause any jank, so the interface remains at 60FPS. It exposes a good number of params which you can tweak to suit most needs. Personally, I think it's not a big deal, as long as the UI runs smoothly. It takes a few extra ms for the view to catch up if I scroll really fast... But I've had similar the same experience with Apple's Numbers and with browsers trying to render huge HTML tables and it hasn't bothered me.

I've gone back on forth on this topic quite a bit. I used to be a strong believer you should virtualize everything. But then you've broken in-browser search, and you find yourself having to write and support even more code. Using canvas? Say goodbye to accessibility. Now, I'm not saying this is the case for your use-case, but I think that in some cases it's worth seriously reconsidering the design and just going with a simple table that leverages built-in browser functionality and traditional pagination. If you have so much data that you struggle to load and display it with JS, it may be a good idea to take a step back and explore alternative strategies for presenting the data to your users. As an extreme example, a 1 million by 1 million table would probably contain too much data for any consumer to really make sense of it. I only say this because I had a couple experiences where having heard that might've helped keep things simpler. I'll still happily reach for react-virtualized when I find a situation that merits its use.

[0] https://bvaughn.github.io/react-virtualized/#/components/Gri...

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#74

Post by TheAceOfHearts »

kamranasif wrote: post #60
tlrobinson wrote: post #26

Earlier quoted context omitted.

React Virtualized is also great: http://www.reactvirtualized.com We (Metabase) switched from FixedDataTable to React Virtualized and are happier with it. The only major issue with it is doesn't have fixed columns/rows built in, but it's pretty easy to compose a couple Grids with ScrollSync to get that behavior ( https://bvaughn.github.io/react-virtualized/#/components/Scr... ) FixedDataTable has performance issues wi…

Maintainer of FDT2 here. One of the reasons we decided to maintain this library is that it does virtualize both columns and rows. We use it at Schrodinger for our enterprise platform and have demo'd support of billions of rows. This is possible because we don't use a wrapper DOM element to handle scrolling. Right now we are migrating all the state to Redux for better maintainability and performance and hope to make e…

I've gotta admit I'm weary of the usefulness of a table with billions of rows. Doesn't that just drown the user with noise? Have you explored alternative means of presenting the data? Billions of anything sounds like too much information for any human to make sense of and process. Could you explain a bit about your use-case?

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#75

Post by TheAceOfHearts »

mishoo wrote: post #64
sandGorgon wrote: post #23

If you can productize this, then you can potentially build a business around this. The most feature filled spreadsheet component today is Handsontable. My company pays for the enterprise version of it...And we wish there was something better.

Take a look at Kendo Spreadsheet too: http://demos.telerik.com/kendo-ui/spreadsheet/index (bias alert: I'm part of the team) It's not free, but IMO it's the most Excel-like Web-based spreadsheet money can buy. You get support for Excel syntax and formulas, hundreds of Excel functions, XLSX import/export, print-to-PDF, virtual scrolling, OS clipboard integration, etc. — and it all runs in the browser.

I'd love it if kendo-ui tool a page from Highcharts and provided a free non-commercial license [0]. I first tried out Highcharts in college, after that I used it for a couple personal projects. Eventually I found myself needing a powerful charting library for my job, and by then I was so familiarized with its capabilities that buying a license was a no-brainer.

If I tried and found myself liking kendo-ui, I'd probably end up even more frustrated from not being able to use it for personal projects.

EDIT: Just wanna add that you guys have done great work. Poking around the component demos is really slick.

[0] https://shop.highsoft.com/faq#Non-Commercial-0

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#76

Post by david927 »

csours wrote: post #72
david927 wrote: post #68

Earlier quoted context omitted.

Error in Case 4: There is no error here, only madness. Then give me madness. The problem is that spreadsheets are one of the most natural interfaces for data that we humans have, and even with Microsoft and Google's efforts included, current spreadsheets on a website (SoW) suck. So let's say the y-axis is importance of function and the x-axis is compelling implementation --> voila! Right there, plotted on the graph y…

> spreadsheets are one of the most natural interfaces for data that we humans have Spreadsheets are natural for data, but not for humans. Spreadsheets are excellent for prototyping and data munging; and spreadsheet prototype apps are even fine for personal or small team use. When you get medium team size or multiple small teams that spreadsheets break down. Part of that breakdown is in distribution - which SoW solves…

So the only reason it's not natural for humans is that current implementations of spreadsheets have issues with implicit rules?

I don't think that's a failure of the model but merely of the implementation. We can fix that. The model is right.

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#77

Post by repsilat »

csours wrote: post #72
david927 wrote: post #68

Earlier quoted context omitted.

Error in Case 4: There is no error here, only madness. Then give me madness. The problem is that spreadsheets are one of the most natural interfaces for data that we humans have, and even with Microsoft and Google's efforts included, current spreadsheets on a website (SoW) suck. So let's say the y-axis is importance of function and the x-axis is compelling implementation --> voila! Right there, plotted on the graph y…

> spreadsheets are one of the most natural interfaces for data that we humans have Spreadsheets are natural for data, but not for humans. Spreadsheets are excellent for prototyping and data munging; and spreadsheet prototype apps are even fine for personal or small team use. When you get medium team size or multiple small teams that spreadsheets break down. Part of that breakdown is in distribution - which SoW solves…

Spreadsheets are the most intuitive programming environment known to man. Every time you reach for Excel to mung your data, that's opening a repl. The only problem is that Google and Microsoft don't care enough to make them powerful enough to do general purpose computation with, fast enough to build large systems with, versionable enough to enable large teams to use them.

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#78

Post by csours »

david927 wrote: post #76
csours wrote: post #72

Earlier quoted context omitted.

> spreadsheets are one of the most natural interfaces for data that we humans have Spreadsheets are natural for data, but not for humans. Spreadsheets are excellent for prototyping and data munging; and spreadsheet prototype apps are even fine for personal or small team use. When you get medium team size or multiple small teams that spreadsheets break down. Part of that breakdown is in distribution - which SoW solves…

So the only reason it's not natural for humans is that current implementations of spreadsheets have issues with implicit rules? I don't think that's a failure of the model but merely of the implementation. We can fix that. The model is right.

We solve the problems of implicit rules by adding UI and UX so that the rules become explicit.

Anything that solves the problem of implicit rules in spreadsheets is a UI or UX solution.

The question is, what is the best UI or UX solution?

My position is that the best UX is not a spreadsheet. To your point, it is possible that there is an acceptable UI or UX based on spreadsheets.

The next question would be, how much more difficult is it to create human driven spreadsheets than to create a classic UX solution (something like an input wizard)?

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#79

Post by csours »

repsilat wrote: post #77
csours wrote: post #72

Earlier quoted context omitted.

> spreadsheets are one of the most natural interfaces for data that we humans have Spreadsheets are natural for data, but not for humans. Spreadsheets are excellent for prototyping and data munging; and spreadsheet prototype apps are even fine for personal or small team use. When you get medium team size or multiple small teams that spreadsheets break down. Part of that breakdown is in distribution - which SoW solves…

Spreadsheets are the most intuitive programming environment known to man. Every time you reach for Excel to mung your data, that's opening a repl. The only problem is that Google and Microsoft don't care enough to make them powerful enough to do general purpose computation with, fast enough to build large systems with, versionable enough to enable large teams to use them.

> Spreadsheets are the most intuitive programming environment known to man. Every time you reach for Excel to mung your data, that's opening a repl.

I absolutely agree - REPLs are excellent for prototyping and exploring data and ideas, and spreadsheets are excellent in that role.

Allow me to ask you this then: when was the last time you shipped prototype code? Unless you live dangerously, you don't ship prototype code!

> The only problem is that Google and Microsoft don't care enough to make them powerful enough to do general purpose computation with, fast enough to build large systems with, versionable enough to enable large teams to use them.

I would counter that a more important problem is "productionalizing" spreadsheets - all of the fiddly things you do to ensure inputs are in the right format, etc, etc, along with testing, securing, and deploying code.

Re: Show HN: React-data sheet, Excel-like spreadsheet component

#80

Post by mason55 »

zenlikethat wrote: post #61
clishem wrote: post #21

Earlier quoted context omitted.

If you think it's a constructive comment I'll be writing a bot that scans pages posts on HN, looks on the page for a GitHub link and complains about the license used. Doesn't matter if it's GPL, MIT, Apache, I'll just write some generic comment complaining about each license.

Since the license of this library is MIT and the poster mentions patent attorneys I'd guess they aren't worried about licensing. They're worried about getting sued by Microsoft, Google, etc. for patent infringement.

Host on Azure and use Microsofts patents against the when they sue you
Post reply on HN