Nah... why should it? It works and it does what it needs to do and more if you decide to hook into the Windows API or Mac’s API.

Want to parse 500mb structured XML file? Okay. Takes 3 seconds or so.

I had a lot of fun creating a full featured & modern look & feel application using Excel’s VBA runtime as my platform. Sure... I had to create everything from scratch, but learned so much while doing it. Kind of miss it at times since I now work with Java.

By the time I moved jobs, the codebase was +30k lines and even built an auto-updater, auto-installer, diagnostic, and AD type of authentication for the app, but most importantly saved tens of thousands of hours by automating reporting, analysis, detect errors, and querying that analysts, accounting, and some BI’s would do as part of their normal work.

VBA is great for analysts to work in Excel all day & every day who want to get into programming a little more, but want to have it apply directly to their daily work.

Now.... I wish Access does die...

It'd honestly be a shame if it did (but I understand the stresses that might cause it to happen).

Flash back to ~1986, and Bill Gates wrote an article for a Byte magazine special edition in which he described a unified version of BASIC implemented across a suite of GUI productivity applications.

Keep in mind, this is before Windows 3.0 and the Microsoft hegomony, before Word for Windows, (and Access, Project, Visio, etc.), before OLE/COM/ActiveX/IDispatch, and all of which are arguably necessary to complete the vision he outlined in the article. Ten years later, the vision of the article was realized, and thirty-five years later, it not only still exists, it's still useful across a huge cross section of computer users. (Despite the radical changes in the industry over that time.)

Microsoft has gotten a lot of flack over the years, and a lot of it has been earned, but the ability to identity a useful target state ten years in the future and rally an organization to achieve that goal is an amazing accomplishment.

I'm working on an excell addin right now. It doesn't use VBA (it uses microsoft interop libs for .NET) And I have zero interest in using VBA, but I will admit, it would have been much easier to do this project in VBA instead of C#. Debugging would have been easier. I could debug inside the VBA code-behind instead of Attaching to the excel process in Visual Studio. Deployment would have been easier. I could make an .xlam file and just give it to the users instead of A separate visual studio project that creates an installer on each build. Excel interop would have been easier too(probably, I'm not 100% sure.) But using the Microsoft.Office.Interop.Excel libs are kinda hard. I don't have any good reference material for this lib, but for VBA, there are tutorials all over the internet for doing common things. I mostly avoided VBA because I prefer the syntax of C#. I would imagine most people that only know VBA would have no interest in using C# to write office interop code, and I don't blame them. As for javascript, I doubt anyone that knows VBA well would have a hard time learning javascript, and if the codebehind for excel was slowly migrated to that, most devs would welcome the change.

Microsoft should rather provide a better path toward office automation rather than just frustrate users. As I have seen it, javascript isn’t even remotely close to the sort of integration that made the success of VBA. Like how can I save a javascript macro as a user? Javascript user defined function?

VSTA was a good attempt in its time, a mini visual studio integrated in office with VB.net and C# instead of VB6. That would have been cool.

As long as Excel is used by businesses, VBA will be relevant. Excel will probably continue to exist - and be supported and updated to ever newer versions - forever, so it stands to reason that VBA will probably also exist forever. Unless Microsoft goes bankrupt and Excel isn't picked up by another company. Which will also probably never happen.

    let javaObject = CreateObject("java:com.company.library.ApiClass")
    
    print javaObject.version

Quote: "What Will Replace VBA? Short answer: JavaScript. "; and author follows with some logic about JS vs VBA using cross-platform.

Except this will never happen:

1 - M$ loves backward compatibility. It's what keeps their software being sold all these times. Worse case JS will have bigger user share and that's it, but M$ will never cut VBA out.

2 - Also majority of business is done on Windows. Cross-platform means absolutely nothing to corporations. The day that Windows dies that's the day VBA will die as well.

3 - JS as golden boy vs VBA? pleease. Best case scenario you're switching from one ugly boy to another ugly boy. Both VBA and JS are horrors. Don't believe me? Go read'em horror stories about JS cross browsers implementations. JS solved the problem of cross-platform only to open the problem of cross browsers. Good luck having Apple implement the same JS in Safari as their mortal enemy from Google in Chrome.

There's really two camps of VBA, the "application builder" and the "spreadsheet functionality" camps.

Application builders are trying to build interfaces for things that will run in a non-spreadsheet (i.e. non-reactive, not always-recalculated-to-be-consistent) mode. That's bound to be brittle, because that's not what Excel is for.

Spreadsheet functionality extending people OTOH write almost 100% what in ordinary programming is known as "pure functional style". Too often to write complex formulas in Excel (even something as simple as the Black-Scholes equation) people have to use multiple cells to keep things tidy and debuggable. You can use VBA functions for that. You can also write short loops to "solve for zero" with the bisection or Newton method etc. as long as they don't run for long. None of that interferes with spreadsheet semantics.

My first apps ever were extremely customized VBA Access databases. I already knew QBasic so doing VBA was easy. It affords a ton of power. I was able to create an entire interface and workflow easily and have everything contained within one Access file. The only downside was when multiple users wanted to use it (I think one had to save/close to let another in). For small things (a workflow tracking a university's scheduling changes) it can be great. Filemaker is a similar tool and both tools allow rapid development and prototyping. It might not be that useful to seasoned programmers, but to people who just want to get something done quickly, and especially for people who don't program much, it's an amazing tool.

Some points:

* I guess with Office365, JavaScript makes some sense, but why not just go VBA to WebAssembly?

* What about the Python rumors a couple years ago?

* I should probably turn my NecroVisualBasiCon library into A book. If you use the Access.Application library, right-click and toggle the hidden members, that COM object has a few extras like loading/saving objects from the VBProject that make e.g. git integration feasible.

* VBA does an outstanding job of providing 80% of what you want and no more.

Excel is one of the reasons I want to leave a career of Business Analyst behind.

Regardless of the process, the last step is always to dump the data into Excel and spend tons of time to create good-looking charts and tables. It usually takes me a full day to do that plus write wiki pages in Confluence (another pain point).

I just want to stay away from spreadsheet -> which means I need to get further from business and get a more technical position.

I don’t think it will. Microsoft might add another macro language but everyone is obsessed with backwards compatibility at MS and I highly doubt they would remove something as widely used as this. I used to be really annoyed by this as an engineer, but in contrast to Google’s culture where products are shutdown all the time I’ve started to come around that users should come first to avoid getting this reputation, even if it does become a combinatorial hell of different versions. I work at MS so I’m biased probably

Ha - good timing! I've been using VBA today and yesterday actually!

Often only a few times a year I use it now but when I do it I feel productive.

In case your wondering I has a previous Excel VBA Macro that I wrote for updating a SQL Server Database based on data in Excel. The macro first has to run checks against data in an IBM AS/400 Database.

I ended up having to pull out the macro to do a bulk update in an ERP. It was faster to do this then re-write in an modern language (especially since I work with the data in Excel first).

As far as I'm concerned, JavaScript (or at least JScript, MicroSoft's proprietary reimagining) replaced VBA 13 years ago. I haven't had to do anything programming with Excel for rather a long while, but way back in 2007 I was already writing JScript programs to automate spreadsheet tasks.

I hate VBA with a passion, but on the other hand it saves me many many hours every month through my ability to automate tasks. I would love for almost any language to replace it, but there has to be some kind of replacement if it goes away.

Between the spread of excel across businesses and MS focus on compatibility it seems rather unlikely. It is kinda ridiculous how much depends on VBA macros.

Weirder things have happened, but whatever would replace it, would create an industry overnight.

I don't own a Windows computer, but I've seen some incredibly interesting stuff come out of the VBA for Excel, which I sadly never have had a chance to learn.

Does anyone here have a side-by-side comparison of the LibreOffice BASIC vs the VBA?

> one of the easiest coding languages to learn if you don’t have a computer science background

Really? A language that has values passed by value, values passed by reference, references passed by value and references passed by reference? (And both late and early binding, and auto-boxing with all kinds of mysterious type-conversions, etc. and so on. And default properties.)

What makes it easy for beginners is the integrated environment, which is also what makes it difficult for more experienced programmers as it doesn't integrate with their version control system and other common tools.

If traders/quants and financial analysts in banks say that they don't need VBA anymore, sure it will die. Otherwise, not a chance. Trust me.

Not sure why they wouldn't go something C#/.NET based. If you're going to go the JavaScript route, at least pick TypeScript.

It's weird to me that we haven't settled on a common, stable, purpose-built high-level language specifically for business logic. Stuff that doesn't change much, that doesn't need to concern itself with the platform, only the business. That code should be portable to whatever shiny new underlying system gets invented; why does it keep having to be re-expressed every few years?

The situation is much better (though still far from ideal) when it comes to data. Everything knows how to use CSVs. Relational databases, from a schematic perspective, really haven't changed terribly much in decades. NoSQL came around but that was really just an alternative option; you don't see everyone scrambling to migrate their SQL data to Mongo. SQL isn't quite a standard, but it would be dramatically easier to migrate an ancient MS SQL database to Postgres than an ancient COBOL codebase to Java.

Well judging from the fact that my first computer my father bought back in 1988 Amstrad CPC 6128 is still alive and kicking with very active community and more development tools than it ever had, I think its safe to assume that software never dies. Only thing it takes is a small dedicated community and it can last for centuries. Partly because father and mothers infect their sons and daughters with their passion for the technology and the the loop never ends. What else never dies is necrophilia in software , apparently people are addicted to declaring software dead prematurely. Oh and of course clickbait because some people are desperate for views. It started with Java back in to 2000s and still going strong. I am not fan of Java but I am also not that delusional to declare Java dead. So no I think its pretty safe to assume VBA is not going anywhere.

JavaScript, for better or worse, is probably the most widely used language out there, by nature of being the language in the browser. The push for cross platform, mobile and web with frameworks that leverage it have leaned in on and expanded JS greatly. The engines are highly optimized (more than any other scripting language as feature rich), cross platform and nearly ubiquitous.

VBA just isn't. Anything not JS is just about a non-starter for the web versions of these applications, and that's where things are headed. If you're on Linux it's probably the only option in the space for a while.

JS is pretty decent, the ecosystem is massive, and you have the option of TypeScript if you want something more formal. Guessing everything MS offers will actually be written in TS, just consumable in plain JS or TS.

Reading the replies to this post, the title is most certainly click-bait and not encouraging deep discussions.

I still think that original Excel macro language was better than VBA. It essentially excel's formula language extended to be imperative language and represented as sheets. At the same time it was user friendly and had kind of lisp feeling.

If there's one thing I've learned in 15 years of IT work, it's that once business users have discovered a thing it will never die.

No matter how outdated, shitty, useless, etc. it may be, some jackass has built their entire workflow around it and has more power than you to prevent that from ever changing.

> I would imagine most people that only know VBA would have no interest in using C# to write office interop code, and I don't blame them.

I'd be happy to use C# but it's so god damn hard to learn those libraries.

The biggest disadvantage in using VBA is speed – not to mention the idiosyncrasies of the language itself, which can make complex code rather painful.

Writing a .xlam addin is easy, except there's no tooling for creating "builds".

On a separate but related note, since writing XML for the ribbon by hand is so annoying (and you also have to write callback wrappers for each Sub you want to expose) I have actually written a python tool that parses annotations from comments in .bas files in a given folder and spits out a .xlam file. Haven't gotten around to publishing it but if folks are interested I can give it a little oomph and finish in the next few weeks, so lmk

There is so much of this I can relate to, I have worked with legacy systems too and have been fortunate in a sense to have to drill into someone else's VBA and thankfully there were people there to run me through those strangeness of it.

While I don't think it needs to continue, I believe it's been replaced in all aspects to date.. I do think that there is a requirement for a knowledgeable person to at the very least lead the re-write.

> As for javascript, I doubt anyone that knows VBA well would have a hard time learning javascript, and if the codebehind for excel was slowly migrated to that, most devs would welcome the change.

One of the main points of contact for my VBA adventure picked up vanilla javascript super fast, and within a few weeks he was already explaining how it could be made semi strongly typed, he introduced us then to a newly formed TypeScript subset and we never looked back.

It's not a language issue, its an understanding issue, give a good engineer/developer/hacker any language and they will figure it out and know how to make it work.

That said, if I ever see VB again, I will still shed some salty tears.

One thing to consider, which I've found powerful, is a hybrid approach where you use vba for what it's best at -- interacting with the Excel object model -- and have the vba load and call a C# xll that leverages the .Net libraries and does all the work that would be tedious to do in vba. For your users, they would simply open a "host" .xlam file, which is the only one they would be aware of, and this file would load additional .xlam or xll files and typically also check for updates to these files. No installer necessary.

For example, your vba code would pick up a range of index (or ETF) tickers from a sheet, use Application.Run("lib.constituents") to call a C# function that pulls the stock tickers and weights that represent each indices' constituents, your vba code would receive back an array of arrays and use Excel's row grouping feature to group the members & weights under the parent index and perhaps add some formatting and\or formulas.

The advantage of this division of labor is that you get faster dev & debug feedback loops within your Excel-centric code, while minimizing the amount of time you spend working in a dev environment that has stood still for 20+ years as others have raced far past.

I’m the other way. Started a large project in VBA once, jumped over to C# interop and never looked back. I found the libraries to map fairly well to the same named functions in VBA when it came to worksheet manipulation. My biggest issue was that the interop has quite a bit of latency. You really want to accomplish as much in one call as you can (i.e. read whole ranges into an array instead of looping through cell by cell).

Edit: If this is internal, you can also set up one click deployment to some folder on the network that will auto update the add on for end users.

I'm curious, what's the upside of not using VBA? Aside from being cool, obviously :)

Agreed. JavaScript has no real upside here besides being fashionable. whereas built-in C# with access to the .Net framework would be really powerful.

I think there's a different focus with JS vs VBA or C#. JS is the future because of Office365 ie. Cloud/online apps are the future.

I don't think C# integrates with the o365 codebase, but I'd consider both JS and C# as attempt to move people to good dev practices, C# with IDE/versioning/debug etc and JS with the approach of funneling data in and out of excel eg. Cloud compute, and then using excel for basic functions that don't involve using macros etc.

VSTO to the best of my knowledge is still a thing. And you could indeed do some pretty cool stuff with it!

But it's not as easy to use as VBA, nor was it incredibly easy to work with from a development standpoint when I last tried to use it (Maybe I was doing it wrong, but I had to do a full VS install with the add-in module.)