Heh, from where I stand "the no-code movement" and "the same mundane ideas rewritten with ever-more-complex toolchains while legions of programmers argue why the latest blend of frameworks offer things completely impossible before them" are much the same thing. What the industry needs is the boring grunt work of replacing frameworks with libraries. Rather than generating a 55-file "project skeleton", we should be able to call standard libraries written in plain old code and get the same behaviour, adding the extra stuff as and when we need it.

Why don't we have a library stack where I can define some datatypes and get database migrations, CRUD REST endpoints, and a basic editing web UI, in a maintainable language where I can understand where all that's coming from and incrementally start customizing? I'm pretty sure I've implemented all the pieces you'd need, scattered between the codebases of my last three or four employers: in a language with a decent record system it should be a one-liner to build a set of HTTP routes for a given datatype, not through invisible magic but through a function call that works by plain code.

But it's in no-one's interest to package that up to release it. A traditional business doesn't produce new systems often enough to make a general toolkit. A consultancy does new systems but has no need to make them maintainable (thus Rails, which does all the automatic spinning up but doesn't have the comprehensibility to be reliable). And there's no money in selling libraries to developers, partly because developers would rather do it themselves but mostly because a library you have to buy will never be popular enough to get talented developers using it. Occasionally a huge corporation decides it's worth making a framework for their in-house applications, and even more occasionally they find it worth publishing to the outside world, which is an astonishingly inefficient process for our whole industry to depend on.