Until Windows drops 32-bit compatibility, VB6 apps will continue to run fine even if they do look f'ugly against todays UI design. In fact there's probably still a significant amount of industrial/heavy-commercial in-house applications written in VB still in use.

I can see a use case for TwinBASIC in maintaining these legacy apps, as the VB6 IDE no longer behaves itself under Windows 10/11. If it offers compilation to 64-bit (pseudo)code, then these apps will gain an extension on their usable life.

To be fair, it's been that way for a long time. VB6 (and VB5) compiled to machine code, unlike earlier versions which were criticised for interpreting bytecode ("P-code").

Now, VB required some runtime dlls, namely msvbvm60.dll, and several ActiveX controls, but that feels small compared to even the .NET Framework. And tiny compared to your implied comparison with Electron/Chromium.

And it doesn't even have true threading in the language, you can do it, but its not like a language construct. What is beautiful about VB6 is your ability to use native DLLs and parts of the Win32 API as well.

I've been wanting to see a VB6 successor for a long time. I have debated paying for Xojo but I'm not a fan of their docs and havent built anything worthwhile yet to justify buying a license.

Visual Basic was mostly just used for line-of-business software -- forms, reports, etc. That's mostly been moved to the web, but it was seldom used for anything where performance was important.