http://gambas.sourceforge.net/en/main.html

We don't have a real successor to VB (yet) because people always tend to overlook things and only focus on specific stuff, like the language or the form designer but those pieces weren't what made VB, it was the entire package - take a single element out and it falls apart.

Things i've seen people do in attempt to recapture VB:

* Start writing a compiler. The compiler part of VB was an afterthought (and wasn't even there in VB1-3), the important part is the IDE. Whenever i see someone trying to remake VB by even thinking about a compiler first, i'm certain that it'll fail (even if the project is made, it wont be VB, the developers' hearts are not in the right place).

* Ignore the "live" aspect of working with VB, like the ability to pause a program, modify it and continue or to execute statements, pause on errors, modify the code, continue, move the execution pointer around, modify variable values. You are interacting with a live system, there is no edit-compile-run cycle, it is just edit-run. Most attempts try to separate the IDE from the runtime, as if you were writing a C program with a form designer bolted on. A better system would try to eradicate the difference between designtime and runtime (e.g. allowing modifying forms while the program is running), not introduce additional steps or separation.

* Ignore the IDE. It was named "Visual" Basic for a reason. The documentation calls editing the forms as "painting the GUI" because it is a visual process. The IDE tries to make things as visually seamless (not always with success, TBH) - the form designer is the form itself, placed wherever you place the form (later this was diluted a bit in VB5 but you could switch to SDI to get the real deal), double clicking a button has you typing the code immediately for that button (or any other control's default event), you get a property panel with live editing of properties and in later versions (VB5, VB6) you even get those properties categorized, etc. You get a visual browser for every available class, method, function, etc available even with some brief documentation.

* Ignore extensions and composition. The entire reason Visual Basic exists is that Windows 3.0 got DLLs and someone (Alan Cooper) came up with the idea of using those DLLs to create reusable visual components. While Visual Basic does have a handful of "internal" controls (labels, listboxes, scrollbars, edit fields and a couple of others), most people using VB use external components.

* Try to make it possible to do everything in it with the apex of that being trying to write the language in the language itself. VB was the best example of a right tool for the right job - and an example that was very often ignored. VB's best use when was it was used to create front ends to machinery written in other languages that were better suited for the task. Sadly Microsoft dropped the ball here and made it too hard to expose components to VB since COM/ActiveX was a PITA and the only alternative was using DLLs (something they made way worse with VB.NET and C# by allowing only DLLs). This is something i never understood - they had their own C/C++ compiler, this was their own language, why couldn't they add an "add C++ header" (or just C header) command in the project window and have the IDE automatically parse and expose to VB whatever defined in the header? Even if it was only a subset of it (i wouldn't expect macros to work for example) it would be much easier. I believe that this is what led many people who otherwise should have known better to try and do too much in VB - because using another language had a lot of friction - and as a result, people who want to "revive" VB, try to solve the issue by improving the "do everything in VB" part instead of making interfacing with other languages easier.

* Focus too much on the language. This is really related to the first part, but really, i just cannot stress how often people miss the forest for the tree when it comes to VB - many programmers are attracted to VB's language like moths to flame. Originally VB was supposed to have pluggable languages and i don't know why this idea was scrapped - i'd guess it would make learning the system harder - but it is a testament to how unimportant the language was to the entire package.

* Try to bolt an existing language that simply doesn't fit. I'm not going to give examples for those because i don't want people to focus too much on defending their favorite language, but while the language isn't that important, it still needs to feel right at home with the rest of the package - especially the IDE. Every feature of the language needs to be able to be represented in the GUI itself and that without being overwhelming (to understand what i mean with overwhelming, imagine working on an XML document produced with LibreOffice with a plain text editor - the document is technically a text file and you can technically edit and even write new parts on it with the text editor, but it is clearly not a good fit. Similarly it isn't enough to be able to represent the language in a GUI, its features also need to be a good fit for visual representation through a GUI). Note BTW that taking an existing language and altering it to make it a better fit might work (after all that is what Microsoft did with BASIC).

There are other things of course (and i certainly do not include the most common case of people starting with an idea and going nowhere - but i suspect an easy language like VB attracted a lot of people who simply didn't know what they couldn't do), but the above are some of the main stuff in my mind (and this post is already too long).

Personally i find the desktop development process today a broken mess and most "modern" approaches to really be rooted in 70s mindset. GUI is by its nature graphical, making GUIs should be graphical itself - yet most systems regressed to text based descriptions.

The best system in active development today is Lazarus with Free Pascal. It is far from a VB alternative (despite how much people compared Delphi - Lazarus is practically an open source cross platform Delphi - and Visual Basic back in the 90s, the only common those two systems have is that they use form designers that if you squint hard enough look kinda similar - everything else is different) and IMO doesn't even reach Delphi 1's level of integration, it is kind of a mess in several places (some due to Free Pascal having a kitchensink philosophy, but also some due to just plain old sloppiness) and its cross platform support while there, has issues on anything except Windows (and personally i dislike how the only backend that really works on Linux is Gtk+ 2 and that they do not focus on their own backend - but that issue i have has a lot to do with how broken and hostile to backward compatibility is desktop development on Linux).

Still, i do all my complex GUI stuff on Lazarus. Now and then i also work on a GUI toolkit that i hope one day to use to build my dream GUI development environment on Linux (so i can finally get rid of any Windows dependencies) although the entire Wayland story with all of its limitations and other issues puts a major block there (and makes me lose my interest on Linux desktop altogether).

So many people are talking about missing the power of VB, early Delphi, Turbo Pascal etc. and WASM is first tech for a while that looks like it could take that power to the browser.

A lot can also be done with an interface designer like Glade.

Delphi is still around.