Whenever the discussion of VBA comes up, particularly about its relevance or whether it’s becoming obsolete, I often encounter the same reaction: “VBA? Isn’t that just a macro language?” It’s almost always framed this way—a language for creating macros. But what does that really mean? I usually follow up by asking: What do you mean by VBA being a macro language? Most of the time, the response is a blank stare. The assumption is that everyone knows what that means, but do they really?
So, what is VBA, really? When someone asks me to define it, I like to keep it simple: VBA (Visual Basic for Applications) is the most direct and tightly integrated way to programmatically manipulate the objects within Excel. It allows you to automate tasks, extend functionality, and interact with Excel’s object model in ways that aren’t possible with point-and-click operations alone. But here’s the real question: Before you make any pronouncements on whether VBA is useful or obsolete, ask yourself—when was the last time you needed to programmatically manipulate the objects in Excel?
At this point, the conversation often falls silent. Why? Because if you don’t even know what it means to manipulate Excel’s objects programmatically, how can you assert that VBA is no longer relevant? If you’ve never needed to use VBA or even understood what it’s designed to do, it becomes challenging to have an informed opinion about its usefulness or future.
Now, let’s dive deeper. Often, VBA and Power Query are compared, as if they are equivalents. But here’s the thing: they’re not. Power Query is an ETL tool—designed for extracting, transforming, and loading data within Excel and Power BI. It is not a programming language designed to integrate with Excel’s object model. In fact, Power Query doesn’t even expose itself as an object that can be manipulated via VBA or any other programming language. So, in that sense, it’s outside the realm of programmability altogether.
Power Query is, by design, limited in scope. It’s built to do specific things within Excel and Power BI—things it does very well—but it’s not a general-purpose programming language like VBA. It doesn’t allow you to program against external objects, other applications, or even other parts of Excel beyond its data handling capabilities. VBA, on the other hand, can address and manipulate almost any object within Excel. And it doesn’t stop there. With VBA, you can extend Excel’s capabilities by creating your own objects and manipulating them through custom classes, thus pushing Excel far beyond its out-of-the-box functionality.
So again, my question to you is this: How often do you need to extend the capabilities of Excel? If your answer is “never,” then perhaps VBA isn’t relevant for you. But if you’ve never explored these possibilities or needed to automate or extend Excel’s core functionality, can you truly declare that VBA is obsolete or dead?
The crux of the matter is this: many people who proclaim the death of VBA have never fully understood its purpose or used it in contexts where its power shines. They may be enamored with new tools like Power Query, which are incredibly useful but serve different purposes. The comparison is not apples to apples.
So, before writing off VBA as a relic of the past, ask yourself: Do I know what VBA is truly for? Have I ever needed the capabilities it offers? If the answer is no, then maybe it’s time to reconsider the sweeping declarations about its future.
This is a podcast by Hiran de Silva. Narrated by Charlie.
Add comment