[mikeappell]

I think this is only partially true. There are aspects of coding which can be abstracted away, either because they're essentially boilerplate or because a simpler description of the solution is sufficient. Ideally if a more complex description is required, one can drill down into the simplified low-code description and add sufficient complexity to solve the problem.

I mean, couldn't many of the existing frameworks be described as low-code wrappers around more complex work flows and concepts?

[karmasimida]

> many of the existing frameworks be described as low-code wrappers around more complex work flows and concepts

Using frameworks, you are still using the language itself to command the frameworks. For example, if someone claims oneself as a React programmer, nobody would assume that someone didn't know Javascript.

So to efficiently use one framework, you should master both the language + framework. In other words, the complexity not only remains, but also accumulates.

But this is contradictory to low/no code's selling point, as they are targeting non-programmers.

[fapjacks]

This only goes so far, though, with frameworks. In my experience, the vast majority of people that make claims about a particular framework do not understand the abstractions they are building upon. In fact it is sufficiently reliable that I have found this to be an excellent hiring signal, to probe how well a person understands the abstractions in frameworks they use, but also to probe how they diagnose and fix holes in their own knowledge.