VBA Will Never Be Obsolete – Part 3: A Direct Challenge to Paul Barnhurst

Let’s get straight to the point. One of the most basic and commonly used examples in programming is writing “Hello World”. So let’s do that—right now—in Excel.

We’re going to programmatically write Hello World into cell D4. With VBA, this is as straightforward as it gets:

Range("D4").Value = "Hello World"

That’s it. One line. One object. One property. One value.

You run the code, and the words “Hello World” appear in cell D4. Instant. Elegant. Direct.

Now, let’s bring in the tools that Paul Barnhurst refers to as VBA’s “successors”: Office Scripts, Python for Excel, Power Query, and Lambdas. The implication in many recent threads is that these technologies are somehow rendering VBA obsolete. But here’s the challenge:

Can you do what we just did—in one line—in any of those tools?

Let’s examine that honestly.

Office Scripts?

Well, not on the desktop version of Excel. You’d need to:

1. Save the workbook to OneDrive.
2. Open it in Excel Online via Office.com.
3. Write a script in TypeScript to set the value of cell D4.
4. Run the script in the cloud.
5. Download the workbook back to your desktop (if needed).

Yes, technically it’s possible—but only via the cloud. Office Scripts are not designed to manipulate the native COM (Component Object Model) objects that make Excel on Windows so powerful and versatile.

Now imagine putting that operation in a loop to run a thousand times.

Is that practical? Of course not.

Power Query?

Power Query is for data transformation, not direct object manipulation. You can import, transform, and load data—but you cannot tell it to “set the value of this specific cell” at runtime. It was never designed to do that.

Lambdas?

Excel’s new Lambdas are exciting for formula lovers. But they exist within the grid—they don’t manipulate the grid. Lambdas are not imperative scripts. They cannot tell Excel to “go do something.” They calculate, they don’t control.

Python for Excel?

Python is powerful, no doubt. But even with the recent integration into Excel, you are working in a sandboxed environment. Python in Excel can compute values and return outputs to cells, but again—it’s not designed to manipulate Excel’s object model. If you want to write directly to a cell from an external Python script, you’ll have to go through APIs or use pywin32, which is itself a wrapper for COM.

So, if you’re using COM… guess what? You’re doing what VBA already does natively.

So What’s the Point?

VBA is not just a language. It’s the only programming language baked directly into Excel that can manipulate Excel’s object model without friction.

Take that away, and you’re forced to create awkward round-trips through cloud services, APIs, or scripting sandboxes just to do what VBA does in a single line.

Is that progress?

Or is it a reinvention of the wheel—with more complexity, more limitations, and less clarity?

Final Thought

To remove VBA from Excel would be like removing the steering wheel from a car because you’ve introduced GPS and Bluetooth. Those other features may be shiny and modern—but if you can’t drive the thing, what’s the point?

VBA is still the only tool that gives us full, real-time, programmatic control over Excel. Until something else offers that same power on the desktop, offline, immediately, and natively, VBA will never be obsolete.