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 UI was copied, but what is almost always needed is an input wizard with validations and workflow along with a reporting backend.
Case 2: You have a database that you need to share in a human readable format.
Error in Case 2: Implement export functionality instead, you will never be able to implement all the features of Excel, and at some point someone will need that feature.
Case 3: You have a very small and well defined case that actually calls for SoW!
Error in Case 3: Your very small SoW app will grow and grow and strangle you.
Case 4: You want to challenge the stranglehold of Google Sheets and MS Office 365.
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 you can see that this is something that needs to be worked on.
I understand your reasoning: you've created a spreadsheet-styled labeled grid in no time and you're pumping your fist, only to find out later that it this is way less than 1% of the effort you will eventually have to dole out to make a basic, respectable spreadsheet. The landscape is littered with 1% efforts that look good until you start working with it.
My point, though, is that this area is too important to not try harder, to not see more true attempts.
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'.
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.
I don't think that's a failure of the model but merely of the implementation. We can fix that. The model is right.
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)?
People get fixated on the code or UI in front of them and they don't think about the actual use cases.