> In the 90s CRUD apps were a solved problem. Then in the 2000-2005 or so they became graphical (access, foxpro, dbase, paradox, filemaker, and yes visual basic and delphi ...) and it was trivial to get CRUD apps done.

Because CRUD apps were for one platform, running purely locally, not dealing with disconnected clients, concurrent clients modifying shared data, unreliable database connections, clients with arbitrary screen dimensions, resolutions and orientations, or in arbitrary human languages. I think you underestimate the scope of modern CRUD applications.

A lot of that is self-inflicted complexity and following latest business trends (read: mostly hype). Things like opting for distributed cluster and map-reduce where a couple of unix commands piped together, running on a mid-tier laptop would do. Things like going with the latest and greatest web framework, that incidentally pulls in 5-layers deep stack and thousands of dependencies into your workflow.

Also related is typical business optimization - which usually means externalizing costs to users. Like, "CRUD apps were for one platform" - the cost of doing them for multiple platforms is at worst linear with the number of platforms, and most of that cost can be moved to a constant factor if you design your architecture correctly. It's a big deal, but it's not always that big of a deal. And contemporary alternatives result in applications sorta-working on multiple platforms at the price of one, but having half (or less) functionality.

The framework is intended as complexity management. Instead of picking each of 20 components each of which has 7 choices with different tradeoffs and figuring out which subset of choices delivers an acceptable complete picture just read how to use the components we have picked for you in a suggested fashion.

The result may be complicated under the hood but may be easier to operate as well.

Problem is, this often backfires - you end up using 5% of the power of the framework, but spending 95% of the dev time fighting it to achieve what you really want.

In my experience this is a sign that you've picked a wildly unsuitable framework, rather than that the very concept of a framework is wrong.

In my experience, a wildly suitable framework for one person will almost certainly be wildly unsuitable for someone else, especially if that framework is especially opinionated. Appealing to every use case would mean a proliferation of frameworks with very subtle differences, leaving a prospective user entirely confused about which one to use.

That's not to say that there's no place for frameworks, but it is to say that there's value to being able to piece together the equivalent functionality (or at least the critical subset thereof) from unopinionated "do one thing and do it well" components with relative ease and minimal pain.

I think the "relative ease and minimal pain" option is usually picking a framework and working with it as it's intended to be used.

Unfortunately, "picking a framework" for which "working with it as it's intended to be used" actually matches with the user's intentions tends to be the excruciatingly difficult part. Best-case: the user happens to find the perfect framework for one's use-case. Common-case: the user gets by on hacking the framework to do one's bidding, regardless of how it's intended to be used, because the user can't find one that actually satisfies the user's requirements.

See also: the proliferation of Excel spreadsheets driving business logic pretty much everywhere outside of Silicon Valley (and in some cases even within).

I don't see the relationship there... end users choose Excel because it's the only thing that's available to them. For a professional programmer you should not only have better judgment but also have some familiarity with the frameworks available for what you want to do.

I worked as a system administrator around when they were EOLing Windows XP and I think you are really underestimating the benefits of Web apps here.

In the late 1990s IBM Lotus Notes / Domino ran on multiple platforms and worked fine for CRUD applications with disconnected clients, concurrent clients modifying shared data, unreliable database connections, clients with arbitrary screen dimensions, and multiple human languages. The underlying architecture was a bit ugly but it worked.

As an industry we have absolutely regressed in many ways. Web application make distribution easy but almost everything else is worse.

For all the hate it got, the Notes/Domino platform did some things really well.

Sure it's complex. But WordPress works fine. Why can't a crud tool ?

What I wouldn't do for a tool like powerbuilder today...

That said, html + css is the wrong tool for applications and we keep jamming that square peg through the round hole.