How maintainable were creations on those old RAD tools? Because in my limited experience problems quickly outgrow them or become nigh impossible to comprehend monstrosities.
It depends to what you compare it to I guess, I think Qt fares pretty well once you get over the original learning curve for instance.
But these days it seems that the standard is web-based interfaces and honestly whatever scaling problem these "old" RAD tools have, the web has times 20.
I was late to the webdev party, I only reluctantly started to write JS a couple of years ago and to these days I'm still baffled by how barebones it is compared to the GUI toolkits I was used to. You have to import a trillion dependencies because the browser, despite being mostly a glorified layout engine, doesn't really support much but bare primitives.
Thinks like date pickers or color pickers are a recent development and are not supported everywhere.
Making range inputs is not supported by most browsers and requires a heavy dose of javascript and CSS to achieve, and you end up with something that won't look or feel like a native control in all browsers.
Ditto for treeviews.
Styling and customizing combo-boxes is so limited and browser-dependant that you have dozens of libraries reinventing the wheel by creating completely custom controls, each with their own quirks and feature set.
There's no built-in support for translations and localization (unless you count the accept-language HTTP headers I suppose). On something called "the world wide web", that's pretty embarrassing and short-sighted IMO. But you do have a Bluetooth stack now, so that's nice.
Can't speak about Visual Basic, other than it apparently worked just fine for small-to-medium complexity UIs.
On Delphi side, there was significant difference between "code produced by someone just starting out" which tended to make an unholy mess of generated code mixing UI and non-UI operations, but it was quite workable for bigger projects if the developer was more experienced and put some architectural thinking into project (for example, separating business logic and the UI code that called into it).
I suspect this is the key. The RAD tools made application developers more productive, but they came with a downside. If the tool became popular, the vendor lock-in kicked in and it became expensive or the company maintaining it stopped doing a proper job of supporting of it.
Therefore, in the 90s, people became tired of this and looked for ways out of the vendor lock-in. That's why OSS started to get traction, and also Java. It turned out that it is cheaper to develop your business app in Java from scratch, rather than in a commercial RAD tool and then pay up your nose to a disinterested company for maintaining the base on which it stands.
So I think OSS is actually less productive and less polished than it could be (many of the RAD tools are actually really cool, but insanely expensive), but it is still case of worse is better.
I think it's possible that some business DSLs (which are at the core of the RAD tools) will win mindshare again, but it is going to be quite difficult.
(I work in mainframes and there is quite a bit of RAD tools that were pretty good in the 80s, when mainframe was a goto choice for large business apps.)
