Most comments here are in agreement that a ton of programming is doing complicated things, and the complicated part is not "which letters do I press on this keyboard to make code loop a few times". Hence, low-code tools don't solve the right complexity problem. So let's move beyond that.<p>We've all been there, from time to time you have a database table or whatnot that "makes sense" (its columns closely match what users of the software expect to see), and you really just need to expose CRUD operations, add half a page worth of validation and action buttons and then the app is done. (CRUD = standard db ops; CREATE, SELECT (Read), UPDATE, DELETE).<p>Why is the 'low-code automatisation' of that part wavering in and out of popularity? low-code solutions _can_ capture away the right kind of complexity here, no? And it's been tried. In many forms. Many times.<p>In the 90s, 'database-oriented software development' was very popular. FoxPro, MS Access, xbase, that sort of thing. You got the CRUD stuff for free, and all you were really doing was designing forms to lay out the various DB columns and maybe adding special scripted actions to certain buttons. That was pretty much it, already quite low code and trying to, I dunno, turn those scripts into more lego-brick-style low-code solutions seems feasible at that point, too.<p>The development environment was all in on this. The basic interface was a form designer. Then you'd click on a button in the form and 'add an action listener'. The other main view is your columns and tables view where you can click on things to 'add change listeners'. You blessed some form view as the 'main view' which loaded on app start, and that's how you build an app.<p>But FoxPro, MSAccess, that sort of stuff mostly died out. The vast majority of software, both consumer and business oriented, is written in java, python, C#, javascript - those sorts of languages. General languages where database support isn't even baked in - you need to add a dependency no less.<p>The concept was then reinvented: Rails (Ruby-on-Rails) with the notion of 'skeleton' generation, which didn't just generate the barest of bones ("Here is the source file containing the entry point, here is a project definition and all you need to do is edit the names") - but did a lot more than that, giving you a basic but functionally styled web interface for CRUD ops. The development 'model' of rails is then to just add new features and endpoints, and perhaps even replace these CRUD pages one day, until you're happy with your app.<p>But rails is far less popular today than it used to be, and whilst various web frameworks still offer really easy ways to toss up CRUD operations, it seems to me like it's less of a key feature, and various frameworks that don't have it or whose CRUD support seems like an afterthought are still quite popular.<p>Direct rails clones in other languages, such as Grails (for java), have pretty much died out.<p>Why?<p>It's the fact that "the low code experiment has been tried a ton of times and it has failed every time" that teaches me that low-code is doomed to fail. Unfortunately, it doesn't explain _why_ it fails. Just that it is likely to.