That is not really nocode and there is definitely a limit before you need to concern yourself with architecture, structuring code, dealing with complexity etc.

I remember those old visual tool where you could even drag on DB connections. But soon as you have a complex requirement like joining two tables or something then boom you are in yescode.

Microsoft Access 2000 was great at doing table joins in a visual way. It automatically enforced relationships between tables without having to write any SQL.

It is possible to go all the way to writing programs with no actual text source, but the "cognitive impedance match" has to be reasonable. In theory, you could just take MIT's SCRATCH and hook it to a compiler... but it's not the right tool for managing that complexity.

My current feeling is that something like literate programming, with rich source, both declarative and imperative functional code is the way to go for optimal productivity. The front ends that handle GUIs and events match that part of the problem in a profoundly productive manner.

Key word being "were". I'm not aware of widely used similar tools for modern WFEs (which arguably makes up most user facing software these days). I did use something like it back in early ASP days, which were mostly server-side web apps.

The core technology at the heart of both VB6 and Delphi were the Win32 Common Controls, a set of native code GUI elements that are still present in windows. They offered a consistent toolkit across all windows versions. At the time, this was most GUIs.

It is unlikely that any one set of native GUI elements and library calls will ever be applied across all GUIs ever again. The constant churn of languages, the web stack, the vast size range of displays all combine to a situation where GUI application development receded from a high water mark, and it's all downhill from here.

The tools are worse than they were, and are unlikely to recover.

What you can show/build with HTML/CSS/JS hasn't really changed that hugely in the last few years. There are RAD tools for React apparently (retool?) and I don't doubt they wouldn't be appropriate for all uses, but there's plenty of cases where you just need to throw together something quickly where being able to "build" the page layout visually would be extremely helpful. I sometimes get the impression many React-based sites you just get whatever layout happens to be the default (based on HTML5/CSS specs, and whatever libraries/out-of-the-box stylesheets you might use), even if the exact outcome doesn't really match what's been asked for by the UI/UX designer (who almost certainly did use a WYSIWYG tool to come up with the wireframes/static mocks etc).