On a more serious note, would be interesting to see an app builder inspired by the UI and Blueprint editors of UE but tailored for apps rather than games.
Unreal Engine might be a bit overkill since it has too many dependencies built in (you don't need a state-of-the-art 3D renderer and physics engine for UI). Godot is much more lightweight than that (about 40~50 MB from my tests, at least better than Electron), but some might still think that's too much though.
They are okay-ish, if you know the rules of the target code system/platform. (Ie. if you know React, and so you already create components in the UI builder.)
So basically my big problem is that these UI builders don't force/encourage the conventions that result in nice code.
The potential is there, of course, maybe even throwing a chatGPT-like AI in the loop can help with recognizing what the user wants and emitting and maintaining the resulting code base.
A lot of this stuff is out there, it's just usually requiring things like dealing with C++ or some other language.
I don't even need it to be interactive: all I want is a UI-oriented DSL with live-preview. Which is why I personally think SlintUI is currently way ahead of the competition.
The author basically suggests a DSL themselves despite this framework's UI being Rust constructs, as they note the importance of fast iteration and then say that because of Rust's slow compile times it's probably not the ideal language.
A DSL provides more than fast iteration too. It also encourages good code quality by forcing you to separate the app's UI from the rest of the logic. And complete language control means that a true DSL with its own syntax will always be more readable than anything you can embed in Rust's.
This concept of separation is always interesting to me.
In the 1990s, when MVC was first conceptualized, a GUI was (a) native (b) playing the dual role of both View and Controller. It is quite hard (not impossible, but hard) to separate the app's UI from "the rest of the logic".
Consider trivial interactions (i.e. the Controller side of the UI element) like drags. What does a drag do? How do you conceptualize limits on the motion? How do you convey semantics between the Model and the Controller? How do you handle the differences between clicks (essentially drags with no movement) and actual drags? How does the Controller handle both axes? Gestures? etc.
Remember: the UI is the thing that receives input events from <somewhere, and in its capacity as the Controller, alters the Model state, which in turn causes changes in the appearance of the UI (as the View). This then creates additional issues if changes to the Model state are expensive (i.e. the Model contains/controls heavyweight resources), and thus Controller interaction must first work on a "pseudo-model" which is also represented by the View aspect of the UI, until the interaction is complete, at which time, the Controller propagates the actual change(s) into the "real" Model.
Yes, quite a bit of this has been revised/extended/expanded (e.g. Microsoft's View-Model concept), but the basic issues remain, and make the kind of separation you're thinking about hard to do in practice for all but basic data presentation applications.
The problem, such as it is, is that the original examples they tended to use involved systems where the View and Controller were physically separate systems. Consider a medical scan data viewer with (a) a screen (b) a series of controllers to manipulate what appears on the screen.
In this context, all 3 of MVC are clearly identifiable and easy to talk about and understand.
But as it got applied to GUIs where there are no distinct physical controllers and all the interaction occurs intimately tied to the View (i.e. what's on the screen), it is harder to find the boundaries between the V and C parts (and to some extent even the M).