What people forget is that VBA is still built in to every copy of Desktop Excel (press alt f11) and is used by entire industries that are disconnected from the open source tech online discourse. In a lot of locked down business environments its the only automation an employee has access to. If macros suddenly got Thanos snapped out of existence tomorrow the entire economy would grind to a halt. People keep saying VB is dead but it probably processed some of your information today somewhere in some cubicle.
Not going to lie I was exited to see this work lol. Thanks for the tip of the day. I love learning and not sure what I was expecting to happen when I opened up excel and hit alt + f11 but it was awesome to see it open. Already created my first user form and now the rest of the weekend its going to be difficult not to go down this rabbit hole. VB once paid my bills....
There are still companies running their web backends on classic ASP with VBScript. Not to mention VB6-based desktop apps. Thankfully fewer and fewer each year, but they exist.
> Thankfully fewer and fewer each year, but they exist.
Are we sure we should be thankful?
Looking back on VB6, now that i'm in my mid-30ies, i think it had some great points. Basically, a simple app was fast and easy to build and did not require to ship (!) and run (!!!) an entire google chrome instance to render a few buttons, some textboxes and a bit of logic.
I have no issues with VB itself, but the technology is long obsolete and any organization that still has it somewhere in their business is taking on risk that should have been mitigated years ago. Realistically, these apps are not simple apps with a few buttons. I happen to know that the complex, business-critical VB6 app used by the company I interned for 25 years ago is still out there, still supported by the original team! That's a ticking time bomb, as far as I'm concerned.
BTW, the VB6 experience is still somewhat attainable with .NET WinForms (can even use VB.NET if you so desire). Showed my kids how to build simple apps a couple years back and the overall process of dropping controls on a canvas and wiring up events was pretty much the same.
VB.NET is an underappreciated language for teaching in general, IMO. I especially like their choice of keywords being very descriptive rather than traditional. For example, `Overridable` rather than `virtual`, `MustOverride` (for methods) / `MustInherit` (for classes) rather than `abstract`, `Shared` rather than `static` etc.
End of life software running on top of end of life software. Hard to hire for this stack, especially anyone who cares about tech. Security and maintenance nightmare. Interoperability is a pain. Questionable documentation. It all works until it doesn't, and then you're in the world of pain.
A client of mine used Visual Foxpro for… way past its used by date, for a crucial database in a crucial aspect of a crucial industry. When it inevitably failed spectacularly they struggled to get anyone who knew what was up to intervene. Same client kept poor backups.
Recently persuaded said client looking for a new solution to support a new line of business to go with the .NET, actively developed system over the ‘free’ VB6 desktop application that a charity developed a billion years ago and wanders around the industry inflicting pain.
Not all of these issues apply to VBA, which the top level comment brought up,even if they apply to VB6 and the other ones you mentioned. VBA isn't EOL, and Excel certainly isn't.
Lots of people are continually building sophisticated tools in MS Office even though it's not helpful for the resume because it's the path of least resistance for solving problems for the sorts of people who just learned VLOOKUP in 2021 and don't want to learn about XLOOKUP now.
Security, maintenance, interop, documentation... There are arguments to be made. It's not cut and dry that VBA is the worst option for any of those. The patterns for handling them are different than a web app repo or something, but it's not like they don't get thought of and handled on a daily basis.
Only in the context of embeddable web components, and only because running non-sandboxed native code in the browser is a security disaster in general, not because of anything specific to ActiveX.
Outside of that context, ActiveX is simply a well-defined object-oriented API and ABI for cross-language use.
It wasn't any better for Windows 98 with IE bundled in the shell, and audio parsing functions right in the kernel.
Up to the point tons of people chose to revert W98's shell to the Win95 one, having a good speed boost on some PI-PII machnes.
VB6 was a good idea as a RAD tool; but, as TCL 7.x (and the older 8.x releases), the performance wasn't fast enough until some Pentium 3/Pentium 4 for 'big' software. Not an issue for a boring company program or the 234000000nth shareware crossword puzzle software for PC magazines or sites as Softonic. Or some whatever catalog hooking up some Excel/Access libraries, or nice in-sormware forms borrowed from IE DLL to create zillions of similar shovelware.
That kind of niche software was everywhere.
Ditto with some simple games written in VB; but the native ones outperformed VB ones with ease. And, yes, you could call native DDL's, but most amateur programmers didn't do that.
"Boring company program" is exactly what VB was made for. People tried to use it for other purposes because when you have a hammer, you make everything look like a nail, but I don't recall any actual prominent software written in VB outside of line-of-business stuff. "Serious business" in that timeframe was done either in Delphi or in C++.
Every time I try and automate Excel it pushes me towards TypeScript, which I accept is probably the future for Excel automation...except that when you really need to do middling to advanced Excel, Microsoft's Typescript engine throws up its hands in despair and I am forced to pull out VBA.
I really wish the VBA IDE got some love, but I guess that will never happen.
