In other hands, I have seen Excel spreadsheet hundred-products pricelists become a freaking tangle of merged cells, multiple rows for products, spelling mistakes, multiple spaces everywhere, and price cells hand-formatted. And I had to export the contents to machine readable .csv...
“Webxcel creates a full-fledged RESTful web backend from your Microsoft Excel workbooks. It is written in 100% plain Visual Basic macros and comes with a lot of handy tools to help you build the next big thing.”
That's a disingenuous take. You could write one, but it won't be allowed to connect to anything other than itself because Excel doesn't give it the network stack or IO it needs. Unless you use VBA, of course.
In 2010 I was working for a student computer support shop. We had web developers building our own ticketing system. In those days, I was told that everything in the UI was just tables. It was the only way they could get enough control on UI elements before div tags became widely spread.
Html tables are very different from excel tables. Fundamentally html tables were used because rows are a good way to split up the page vertically (you could have one row for the header, one for the content one for the footer). And columns are good for splitting it up horizontally (you could have one column for the side panel, and one for the content, and the last one for an obnoxious blinking ad).
I still love using tables in 2025 for webapps designed to run on old browsers. It's easy to render data into them (it's just headers, rows, columns) and they automatically have a cool, functional look (IMO).
If we somehow manage to solve the two main spreadsheet downsides (imo): testing and change/version control, then spreadsheets would be a terrific programming paradigm.
As it is now I find it very powerful and empowering, but also scary.