Of course, a real pitfall is that you often bump into the limitations of your chosen platform after having completed 80 percent of the work, and then you're either stuck or need to devise elaborate workarounds.
We see many app builders that truly use no code in the traditional sense. The simpler of these tools essentially only allow users to wire together pre-fabricated building blocks, like content screens, chat rooms and the like. More powerful app builders allow logic to be described using visual flow charts.
We have taken the approach of trying to cater to spreadsheet users, and put formulas at the front and center of everything. (Much like Microsoft PowerApps, in fact, though Calcapp precedes it.) Formulas enable complex ideas to be expressed. Ultimately, we put our faith in users having an easier time learning a reactive, functional programming language than they would have learning a traditional, imperative programming language. Fundamentally, the reactive model enables users to express relationships between entities without having to concern themselves with ordering. Supporting only pure functions, with no side-effects, means that we can cache results aggressively, much like a spreadsheet.
There are limits to this approach, though. If you want users to press a button and have different things happen depending on a condition, how would you approach this? Currently, you can't, at least not with Calcapp. Taking actions in response to an event being fired is, per definition, something that requires an imperative approach.
With some trepidation, we're working on enabling formulas to be "run," but only in response to events being fired. These formulas would have access to non-pure functions (changing global state) and even an assignment operator (as well as semicolons, so that multiple statements can be executed). We will likely call them "action formulas."
The challenge is that all this should feel familiar and logical to an Excel user. For instance, we're introducing anonymous functions (lambdas), which can run asynchronously in response to, say, a user pressing a button in a message dialog, but lambda parameters will have default names, meaning that using "arrow syntax" (like in Java and ES6) to name parameters will be optional. We're trying hard not to introduce syntax that would look strange to an Excel user.
I think it's reasonable to refer to app builders supporting spreadsheet-like formulas as "no-code tools." However, what about app builders supporting imperative programming, using a text syntax? We're well aware that we could introduce functions like WHILE, DO and FOREACH that together with lambdas would turn Calcapp into a full (Turing-complete), imperative programming language. Can such a tool still be considered to be a no-code tool?
Probably not. I suppose that's why there's an additional moniker: low-code.