There are exactly 2 types of lowcode environments: One is so complex, and allows the user so much freedom, that it is a fully fledged programming language. Th

There are exactly 2 types of lowcode environments: One is so complex, and allows the user so much freedom, that it is a fully fledged programming language. The fact that it requires me to shove little boxes around in an interface may make it better for some domain specific task, idk. What it certainly does, it makes it next to impossible to integrate in any standard IDE, usually doesn't play nice (if at all) with version control, and searching through code becomes a game of "Where's Walter?". The other is so simple and obviously shoehorned to perform a narrow set of tasks, that it is almost, or completely, impossible to do anything else with it. Which is perfectly fine right up to the moment where the user needs to do something the framework didn't foresee, and suddenly engineers are asked "can we integrate that? we only need one small thing...". Which the framework, being ~narrow and prohibitive~, excuse me, focused and streamlined, usually fights tooth and claw, but engineers somehow get it to work anyway. Until the "one small thing" becomes many small things. And some slightly larger things. And the occasional big thing. And then those same engineers need to rewrite the whole thing, which would be fine, had it not been first "implemented" in the glorious "lowcode/nocode" environment, which suffers all the problems outlined in the first type, so we spend countless hours unpicking a pile of spaghetti made from colored boxes and lines, and the complexity the framework shoved under the rug, to figure out what that thing was supposed to do in the first place. This is the reality of low/nocode environments. And it baffles me to this day, that this idea, which isn't new btw. (it existed under different names since at least the mid 80s), keeps popping up and dominating headlines every few years.