My take, as someone who sells a visual web-app creator (see my profile): If you want it to work well, the UI model of a visual editor has to match up with the

My take, as someone who sells a visual web-app creator (see my profile): If you want it to work well, the UI model of a visual editor has to match up with the data model of the application behind it. Visual Basic worked so well because the objects you manipulated in code were the same components you dragged and dropped onto your window. We already have way too many (and too complex) representations of application state in a typical web app. I count six: Tables in a database -> data model in server code -> JSON over HTTP -> data model in client code -> HTML/DOM -> visual layout It's hard enough to make a WYSIWYG editor for the final transformation (HTML -> visual layout). But trying to WYSIWYG the whole "code -> HTML -> layout" flow is basically impossible. This is why I think you won't see a workable GUI editor as long as we stay chained to today's overcomplicated HTML/JS web stack. What we did with Anvil (https://anvil.works https://anvil.works) was to build a simple UI model from the ground up. We avoid HTML and JS, and provide discrete components that can sensibly be dragged and dropped in a GUI editor, and sensibly addressed from code. This means we can bring back 1990s innovations like autocompleting UI code. But right now it's like having your hand in a cookie jar. As long as you hold onto the full complexity of HTML, JS, Angular/React/etc, you're never going to get that simplicity you want.