As a programmer I found that all no-or-less-code approaches break up sooner than one would expect.
Eventually I chosen to always use the programming language itself for data fetching, looping and leave the templating (lit html in my case) to just passing in the data structures.
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.
All abstractions break down. The more the e difference in in expressivity or complexity between the abstraction and whatever it abstracts, the faster it breaks down.
React is not an abstraction, it's a framework. The core abstraction is "a component takes data only from its parent, and only passes data back up through provided callbacks". The exact spot where this abstraction breaks down is whenever you need to use a hook.
Eventually; but having something less complex than a general-purpose programming language to build prototypes and v1.0 products to test business-purpose fit is really important, too. Lets users have ideas and build them and try them out without having to engage a programmer. Hella valuable for workflow-process design, too. Best to have that one programmer on tap who can fix problems and recognize when it’s too unwieldy, of course.
Eventually I chosen to always use the programming language itself for data fetching, looping and leave the templating (lit html in my case) to just passing in the data structures.