[pbmango]

This is very cool and could be the basis for a huge set of interesting operations - but any time I read about DB <> Spreadsheet discussions they seem to be started by folks who much better understand DBs.

The principle use of the spreadsheet for both power users and casual users is a lot around justifying answers by being able to see the data. The goal is not speed or scale.

If you and sending a report to a superior - clear and visible rows, columns, and "math" makes it faster and easier to trust information for non-technical users.

This same logic is why the spreadsheet is best serving customized, one-off, or changing operations without a huge amount of data. This makes up a huge chunk of day-to-day business decisions, especially in finance where the math is much easier.

I don't think the spreadsheet lasts forever, but its successor will likely be something that presents an easy way to get answers from a set of data that is visible or at least able to be quickly understood, regardless of whether its fast, scalable, networked etc.

[lkirk]

Yes, I would agree that technical and non-technical usability is one appealing spreadsheet use case. I think that another thing I find myself using spreadsheets for is simple data entry. By using a google sheet to enter data, you've already got yourself an authenticated, multi-user web form for easily entering data. It even integrates with google forms, which is a very handy tool for collecting data. It's certainly a lot easier than building it all yourself and hosting it.

Once the data is entered, there are much better tools for data visualization and aggregation (in my opinion). It's nice to have the "frontend" taken care of so that your time is freed up to analyze and extract meaning from the data. I'm speaking from the perspective of someone who does a lot of rapid prototyping and data analysis. There are likely use cases where this won't scale.