Would the low code equivalent from the era be MS Access? And the webification of that being MS FrontPage for UI w/ MS Access .mdb behind? You also had ColdFusion wizards, Dreamweaver app helpers, etc.

Maybe what killed that push was proliferation of cheap journeymen: everyone’s niece wanted to be a web dev, everyone’s nephew a web designer, so it was easier to have your nephew or niece build your site than research which low code boxed software of the age would let you do it yourself.

The niece went down the path of PHP, Rails, and node.js+Angular/React, the nephew down the path of Dreamweaver, Creative Suite, Sketch, Figma. Plentiful cheap hands you can pick up the phone and boss around, nobody needs low code.

Now the tide has shifted. Nieces, nephews, cousins, anyone with a knack are all doing it, but the demand outstrips this supply.

So the demand needs more workers or more automation. Code camps aren’t keeping up, but boxed software is now web delivery. Advertising puts it under general public noses.

Anyone can find a way to build a thing (there are a thousand drag and drop app/site builders now), and the average small biz owner reading the marketing then dragging and dropping doesn’t have a clue whether that’s limiting or good idea.

So yeah what killed RAD tools was the web, but also kids. Now the kids on the web are building the next gen of RAD. And the circle of life continues. :-)

> until VB6-ish started integrating with .NET

Minor nitpick :)

VB6 never had tooling to integrate with .NET.

Rather, .NET could provide an "interop" layer to allow you to consume components written in VB6, or just COM in general. You can also create COM visible components written in .NET that could be consumed by VB6 or even scripting languages such as VB script. But the tooling for that was delivered through the .NET SDK/VS.

But on your other point, you're right, there are probably a bazillion unknown VB apps out there still chugging along doing their one thing for a specific department or company.