[cstejerean]

It's significantly harder to put together a quick GUI application in Python than it used to be in the VB6 days. Just getting all the dependencies installed can be a pain, and then good luck trying to add another button to that app say 2 years later, chances are nothing will build anymore.

[Blackthorn]

Honestly it's harder to put together a quick GUI application in anything than it was in the VB6 days. By losing VB6, we've lost a lot of power and ability to do GUI things quickly.

[sn_master]

WinForms in C# was pretty decent tbh. Not so sure about WCF/Metro/Modern and whatever it is now that Microsoft been releasing. They just stopped caring about consistent UI for apps on Windows altogether since ~2010 or so.

[emodendroket]

WinForms is fine but it makes it way too easy to put all your behavior in the code behind instead of doing things nicely. Which I guess is what you want for a non-programmer tool but it is a hassle for me. Either way the .NET UI situation is a mess and I’ve never seen the sense in picking up the latest flavor of the month since it will be out of favor by the time I have occasion to use it.

[Turskarama]

You say was but winforms is still supported in VS2022 and is probably my go-to if I need to hack together a small windows program.

[sn_master]

Correct, but it hasn't been upgraded in over a decade. It no longer produces apps that are consistent with Microsoft's own the way it was until Windows 7.

[markus_zhang]

What's the bottleneck to build a modern VB6? Just curious.

[emodendroket]

The people most interested in such a product are not those with the skills to build it.

[zubairq]

Such a good comment and totally spot on. Yes, most people with the skills to build a modern day VB6 would not want use it

[mike_hearn]

There are VB like tools. These days they're all SaaS though. Oracle APEX is one well known one, there are plenty of others out there.

There are at least three massive problems faced by anyone who wants to hew closer to the VB6 model:

1. Deployment tech.

2. Getting people to pay for it.

3. Developer culture.

In order:

Deployment. There are tools and UI toolkits today that support VB6/Delphi-like development, but they aren't web based. For example, you can also do VB6 like development using Java or Kotlin + JavaFX + Scene Builder (or Swing and one of the visual form designers for it). This leads to the question of how to deploy the result. Unfortunately, for the past 15 years or so the answer has been pretty much "you can't".

In the VB6/Delphi era the answer to deployment was "take your EXE and stick it on a shared Windows network drive". For internal business distribution this worked fine. Java had JRE+Java Web Start, which also worked fine inside businesses. Unfortunately neither approach works anymore: Windows is no longer ubiquitous, tools don't produce standalone EXEs anymore, users don't know how to handle zips and folders (these skills have atrophied). Also security has got tighter so throwing EXEs around is harder, and people expect software updates to work smoothly. Java dropped WebStart and never replaced it with anything good enough, so the tooling actually regressed with time too.

This isn't fundamental and is fixable. I spent the last couple of years fixing the tooling situation [1]. You can now deploy desktop apps as easily as you do for a web app. Conveyor does signing, packaging for Win/Mac/Linux, and integrates auto-update as part of the packaging process. It will even generate icons and a download page for you and then upload the results. You do still need code signing certificates, however, and getting those isn't as easy or cheap as it is for SSL certs with LetsEncrypt.

A related issue is database and server side logic hosting. VB6 development assumed it was OK to just connect directly to a database using its native protocol and that e.g. every employee would have a DB user. People are more protective of their databases these days and would find this level of simplicity to be radical. I've experimented with that too and given a talk on it at KotlinConf [2]

Payment. VB6/Delphi were developed in an era when people expected to pay hundreds or even thousands of dollars for each version of their IDE/compiler. There were no subscriptions but in practice new versions would come out every couple of years or so, so if you wanted to keep up you'd need to budget a few hundred dollars a year. Skipping versions was common.

Nowadays, people's payment expectations are different. They expect programming languages and platforms to be free and open source. They take absolutist positions on it, saying things like, "it's not open source so I can't ever use this". This rule vanishes if something is a proprietary SaaS however. This kills the incentives to develop better tools for standalone "business crapware" development as mentioned elsewhere in the thread - apps have to be tied to a subscription SaaS or else you can't get paid to work on it. In turn that makes it hard for people to learn by just experimenting locally. For programming languages, every new language that comes along in the past 15 years or so is essentially either a hobby project of celebrity employees (e.g. Go), or a way for rich tech firms to solve tech debt and productivity issues (e.g. Kotlin, Rust, TypeScript), or commercialized by selling long term support (Java). The closest to a real commercial language is Kotlin and that's very indirect, it incentivizes IDE sales, as IDEs are still something people are sometimes willing to pay for (but most use whatever's free).

It's possible that the pendulum will swing back here.

Developer culture. Part of why devs are so hardline on stuff being free is that they want to add it to their CV and learn tech that they can take with them to their next job. This means going where the crowd is. If you wanted to do something VB6 like you'd have to do things very differently to how they are done today (e.g. probably not web based) and that would mean people would stay away just out of fear that they'd stray too far from the herd.

Still, despite these problems, there are ways you can do that. Like I said, take Java/Kotlin+JavaFX+Scene Builder+Conveyor and you have something similar to the highly productive 90s era platforms. You do of course need the confidence to learn tech that some consider old fashioned, and which isn't as widely used as React or whatever.

You could even just go all-in on the Apple platform! Swift+Xcode+their Interface Builder still works.

[1] https://conveyor.hydraulic.dev/

[2] https://www.youtube.com/watch?v=jKeHKe9ttas

[Blackthorn]

Amazing reply, includes a lot of information that I wasn't aware of even though I was the OP there! Thanks.

[markus_zhang]

Thanks for the detailed explanations, makes sense.

[lelanthran]

> It's significantly harder to put together a quick GUI application in Python than it used to be in the VB6 days. Just getting all the dependencies installed can be a pain, and then good luck trying to add another button to that app say 2 years later, chances are nothing will build anymore.

I would say that it is harder, but not significantly so.

Lazarus gets mentioned a lot on these forums, but have you tried it? I use it to whack together decent native looking applications.

It's a single download, it comes with a comprehensive list of components which you drag onto a form to build the GUI, never breaks old apps on an update, and works on Windows, Mac and Linux.