By Hiran de Silva
Randy Austin recently sparked a lively discussion with his thoughtful comparison of VBA and Office Scripts. But as important as syntax and capability might seem, this debate misses the point. The real issue is not whether VBA or Office Scripts is better. It’s whether you need to work with spreadsheets stored locally on a Windows desktop, or with spreadsheets stored in the cloud, typically within a Microsoft 365 tenant or on Google Drive.
This isn’t a matter of preference—it’s a matter of purpose. The choice between desktop and cloud Excel isn’t about which programming language is superior; it’s about how and why you use Excel in the first place.
Start With the Job, Not the Tool
Imagine the simplest use case: a personal spreadsheet for storing lists—contacts, passwords, a vinyl collection, or even your Tinder dates. If accessibility across multiple devices is your main concern, then cloud-based spreadsheets like Excel Online or Google Sheets are ideal. They sync seamlessly across devices and platforms.
But these scenarios are fundamentally personal, not collaborative in the enterprise sense. They are static, isolated, and don’t require automation, system integration, or programming.
The Misunderstood “Collaboration” Argument
Some argue that Excel Online and Google Sheets are ideal for collaboration. But collaboration means different things to different people.
If you’re sharing a single spreadsheet with a few colleagues, cloud sharing might make things more convenient—no more emailing attachments back and forth. But this is still a local mindset: one file, multiple hands.
Real enterprise collaboration is something else entirely. It’s an end-to-end process involving multiple people across multiple departments—sales, finance, production, dispatch—each working with different datasets and files that all feed into a unified business process. This is where desktop Excel still dominates. Why? Because cloud spreadsheets can’t yet handle the complexity, variation, and integration requirements of such interconnected workflows. The hub-and-spoke architecture needed for this level of orchestration is far more efficient with desktop Excel + VBA + relational databases than any current web-based alternative.
So What’s the Case for Office Scripts?
That brings us to the real question: What is the actual use case for Office Scripts?
Office Scripts are the only way to program Excel on the web. But who are they for?
Those using Excel Online are typically casual users with simple, personal needs—lists, trackers, calendars. These users aren’t automating anything complex. They’re not coding. They don’t want to code.
Meanwhile, the power users—the ones building advanced automation and integrating Excel with databases—are overwhelmingly on Windows desktops. And for them, VBA remains the easiest, most accessible tool, precisely because it was designed for non-programmers. (The “B” in VBA stands for Basic, after all.)
Contrast that with Office Scripts, built on TypeScript, which is a flavor of JavaScript—a language never designed for spreadsheets and certainly not for everyday users. It’s harder to learn, has less support, and lacks the comprehensive IntelliSense and object model exposure that make VBA so approachable.
A Familiar Failure: Remember .NET?
This isn’t the first time Microsoft tried to replace VBA with a “developer-friendly” language. Twenty-five years ago, they introduced .NET as the new standard for Office automation. It failed. Why? Because .NET was for developers, not for spreadsheet users. IT pros had little interest in automating Excel, and business users had no interest in learning an abstract, heavyweight platform.
History is repeating itself with Office Scripts.
Google Scripts: A Quiet Parallel
Want more proof? Look at Google Apps Script—the JavaScript-based language for Google Sheets. It’s been around far longer than Office Scripts. And yet, almost no one talks about it. There’s no thriving community, no robust support ecosystem, and barely any training. Why? Same reason: wrong tool for the wrong audience.
Cloud-Based Programming? A Demographic Mismatch
So let’s square this circle:
- The people using cloud spreadsheets are typically not the people who want or need to program spreadsheets.
- The people who do program spreadsheets—building dashboards, automation routines, database integrations—are using desktop Excel with VBA, not Office Scripts.
As Mark Proctor himself admitted, “citizen developers” don’t know how to build databases. How are they expected to learn TypeScript?
So Office Scripts sits in a strange void—too advanced for the casual user, too limited for the enterprise power user, and with no clear demographic in between.
Final Thought: There Is a Future, But Not as You Think
This isn’t to say Office Scripts are useless. In fact, in a properly designed hub-and-spoke architecture, all client environments can participate:
- Desktop Excel
- Excel on the web
- Google Sheets
- Power Apps
- Power BI
- Even non-Microsoft environments
But that requires system thinking and enterprise design. Not a code war between VBA and Office Scripts.
The true conversation we should be having isn’t about syntax, IDEs, or APIs.
It’s about architecture, purpose, and process.
And until Excel training and strategy embraces that, we’ll keep asking the wrong questions—and getting the wrong answers.
Add comment