Beyond the other issues like styling, components were a big part of the VB experience and they had several features that the web hasn't been able to match:
1. They exposed metadata that let them be installed into visual designers and have their properties/events be controlled visually.
2. They could be compiled native code, which allowed people to integrate licensing and make a commercial marketplace for them.
3. They could be written in other languages like C++, allowing VB devs to rely on harder-core programmers to solve some gnarly library or algorithmic problem that was then exposed to them semi-visually.
The web has settled on React components for this but they don't satisfy any of those above features.
There's also a deployment issue. VB apps were "deployed" by just sending someone the EXE, or sticking it on a shared network drive, or maybe building an installer for them. There was absolutely no auto-update story whatsoever if you weren't using a Windows SMB mount which is why the web eventually displaced it, but it was really damn easy to get that first version to people, much easier than for a website (until PHP with shared web hosting got popular).
These days EXEs are much harder to make and send around due to safety features. There's code signing to contend with but also the expectation that you don't impose a choice of OS on users, maybe that you support mobile, that the app will update itself in case of bugs and so on. It's slowly coming back though. With Flutter you can make a mobile app using the app stores to do update, and then bring it to the desktop using Hydraulic Conveyor (my product) to do updates and packaging on the desktop with Codemagic or GitHub Actions to produce the binaries for each platform.
My recollection is that VB6 deployment got messy when you started stringing together lots of third-party components, since they had to be installed and registered system-wide. Windows XP introduced registration-free COM through SxS manifests, but a lot of us couldn't use that for years after XP came out, because we had to keep supporting 9x and maybe 2000.
Yeah, once data files, OCX controls and more got involved you had to build an installer and Microsoft didn't provide any solutions for that until MSI came along. And InstallShield was expensive. So that hurt VB just as people were moving towards the web where you didn't have any dependency issues like that (assuming all the servers were online).
1. They exposed metadata that let them be installed into visual designers and have their properties/events be controlled visually.
2. They could be compiled native code, which allowed people to integrate licensing and make a commercial marketplace for them.
3. They could be written in other languages like C++, allowing VB devs to rely on harder-core programmers to solve some gnarly library or algorithmic problem that was then exposed to them semi-visually.
The web has settled on React components for this but they don't satisfy any of those above features.
There's also a deployment issue. VB apps were "deployed" by just sending someone the EXE, or sticking it on a shared network drive, or maybe building an installer for them. There was absolutely no auto-update story whatsoever if you weren't using a Windows SMB mount which is why the web eventually displaced it, but it was really damn easy to get that first version to people, much easier than for a website (until PHP with shared web hosting got popular).
These days EXEs are much harder to make and send around due to safety features. There's code signing to contend with but also the expectation that you don't impose a choice of OS on users, maybe that you support mobile, that the app will update itself in case of bugs and so on. It's slowly coming back though. With Flutter you can make a mobile app using the app stores to do update, and then bring it to the desktop using Hydraulic Conveyor (my product) to do updates and packaging on the desktop with Codemagic or GitHub Actions to produce the binaries for each platform.