I've been using Mendix for a while now (for a client), which is more low-code than no-code. I enjoy it quite a bit. It's very easy to add a new entity (table) and some screens for CRUD stuff. Even without code you can customise quite a bit, but there's always Java (server) and JavaScript (client) actions. Nevertheless, as with many frameworks, it gets awkward when you move too far away from the 'intended use cases'.
However, I do think that you still need a dev mindset, with dev experience, to use it well. Principles like DRY, loose coupling, code organisation, consistent and informative naming, concise logic, etc adhere just as well. Those hard to transfer skills you build up over time. Although a junior may get things working very quickly, keeping things maintainable and extendable is just as hard, or even harder.
Mendix & Outsystems are pretty popular in the enterprise space and they work quite well. Like you say, don't move too far away from the intended space, but the LoB (line of business) space is vast for big enterprises and that's what these tools are for. There is no need to do 100% as you can get to 80-90% and the rest you don't do with those packages; you do with code. Why is that a problem; you use different frameworks / languages / dbs / etc with code too; these systems are no different; use them what they are meant for and do the rest with other tools. Ofcourse there is more than enough work to be had just creating departmental LoB apps to last you 1000s of lifetimes, but that's another story.
So like you said; I believe you still need to be a dev to deliver with these systems; 'end user programming' is not close outside Excel. People who know nothing about programming will generally make complete monsters with these systems, even after training (I saw it a lot with Outsystems when I click open a business flow).
Real enduser development revolutions we won't see this low-code wave, maybe the next somewhere around 2030?
> Nevertheless, as with many frameworks, it gets awkward when you move too far away from the 'intended use cases'
Right. And that probably applies to many, if not all frameworks, by virtue (vice?) of their design. I don't know Mendix, but I've worked on programming frameworks like Rails, Flask and others, including some in-house company proprietary ones. You sometimes have to work around their limitations with custom code, awkwardly, even Rube Goldberg style at times.
And there can be instances or even categories of apps that can't be done using the framework at all.
The framework giveth and the framework taketh away.
However, I do think that you still need a dev mindset, with dev experience, to use it well. Principles like DRY, loose coupling, code organisation, consistent and informative naming, concise logic, etc adhere just as well. Those hard to transfer skills you build up over time. Although a junior may get things working very quickly, keeping things maintainable and extendable is just as hard, or even harder.