Will OfficeScripts Replace VBA?

Mike Wolfe -

Microsoft recently provided some additional details about the deprecation of VBScript:

VBScript deprecation: Timelines and next steps
Learn about the deprecation of Visual Basic Scripting edition.
TECHCOMMUNITY.MICROSOFT.COMNaveen Shankar Chilla

One of the comments in that article caught my eye:

[OfficeScript] isn't as powerful as VBA...and it never plans to be according to Microsoft AMA.

The link goes to an AMA (ask me anything) reddit thread with the Microsoft Excel development team:

[sancarn]: Will OfficeJS ever get access to an FFI (and thus access to COM API / Win32 API / Objective C APIs)?

[Excel team]: We don't have plans to support this in OfficeJS which powers Office Scripts and Office add-ins, due to our principle of ensuring these APIs work great across Excel desktop, Mac, Web, iOS. We also run javascript code in a low IL sandbox, and you can read more here:  Privacy and security for Office Add-ins - Office Add-ins | Microsoft Docs

This seemed interesting on its face, but to be honest, there were some acronyms in there that I had never seen before (e.g., "FFI", "low IL", etc.).  And so I turned to ChatGPT for some edification:

[Mike]: What's an "FFI" in this context: "Will OfficeJS ever get access to an FFI (and thus access to COM API / Win32 API / Objective C APIs)? "

[ChatGPT-4o]: In the context of the question, "FFI" stands for Foreign Function Interface. An FFI is a mechanism that allows code written in one programming language to call functions or use services written in another language. This is particularly useful when you want to leverage existing libraries or APIs that are written in a different language.

Here, the user is asking whether OfficeJS (the JavaScript API for Office) will eventually gain the ability to use an FFI to access:

  • COM API (Component Object Model API): A Microsoft technology for software componentry.
  • Win32 API: The Windows API, used for interacting with the operating system on Windows.
  • Objective-C APIs: APIs used primarily for macOS and iOS development.

By having FFI capabilities, OfficeJS could potentially call these APIs directly, thus expanding its functionality and allowing for more powerful integrations with native system features and existing software components.

[Mike]: Here was the response from the Microsoft Excel team:

"""
We don't have plans to support this in OfficeJS which powers Office Scripts and Office add-ins, due to our principle of ensuring these APIs work great across Excel desktop, Mac, Web, iOS. We also run javascript code in a low IL sandbox, and you can read more here: Privacy and security for Office Add-ins - Office Add-ins | Microsoft Docs

If you are interested in following our roadmap, follow us on the Microsoft 365 developer blog: https://developer.microsoft.com/en-us/office/blogs/whats-new-for-excel-add-ins-developers-in-2021/
"""

What does this mean in terms of OfficeJS's ability to completely replace VBA's functionality?

[ChatGPT]: The response from the Microsoft Excel team provides some important insights into the capabilities and limitations of OfficeJS compared to VBA. Here are the key points and what they mean for OfficeJS's ability to replace VBA's functionality:

  1. Cross-Platform Compatibility:

    • The response highlights that OfficeJS is designed to work seamlessly across various platforms, including Excel desktop, Mac, Web, and iOS. This cross-platform compatibility is a significant advantage of OfficeJS over VBA, which is primarily limited to the desktop version of Excel on Windows.

  2. Security and Sandbox:

    • OfficeJS runs JavaScript code in a low-integrity level (IL) sandbox to ensure security and privacy. This sandboxing restricts the code's ability to interact with the system at a low level, which is a trade-off for enhanced security but limits certain functionalities that VBA might easily achieve.

  3. No Plans for FFI Support:

    • The team explicitly states that there are no plans to support Foreign Function Interface (FFI) in OfficeJS. FFI would allow OfficeJS to call functions from other programming languages (e.g., accessing COM APIs, Win32 APIs, or Objective-C APIs). This limitation means that certain advanced functionalities and integrations that VBA can achieve through these interfaces are not possible with OfficeJS.

In summary, while OfficeJS offers several advantages, such as cross-platform compatibility and enhanced security, it does not have the same level of low-level system access as VBA due to its sandboxed nature and lack of FFI support. Therefore, OfficeJS cannot completely replace VBA's functionality, especially for tasks that require deep integration with the operating system or other native applications. Developers looking to migrate from VBA to OfficeJS will need to consider these limitations and possibly seek alternative approaches for specific advanced functionalities.

My Thoughts

What I find ironic–given all the hate VBA gets from "real" developers–is that Microsoft's main concern with VBA is that it's too powerful.

Reading between the lines here, there are two primary reasons Microsoft is trying to move off of VBA and toward OfficeScripts:

  1. VBA's reliance on low-level Windows-specific filesystem access, makes cross-platform compatibility nearly impossible
  2. VBA's relatively easy access to the Windows API makes it simply too dangerous to be trusted

Cross-platform compatibility and improved security are worthy goals.

But make no mistake, those features require tradeoffs.  And those tradeoffs mainly come in the form of reduced performance and capabilities.  

Don't Worry: VBA is Not Going Anywhere

One thing that did come up several times is VBA is not being completely abandoned in favor of OfficeScripts:

For VBA, the object model is kept up to date with new features. However, in-terms of tooling, developer experience, mobile & online platform support and Power Automation integrations - we are leading with the JavaScript/TypeScript based solutions as these technologies work uniformly across all platforms.
VBA has kept up with the object model addition for new features. You are right in that new developer experience, deployment, and documentation efforts are focused on the Office-js / Office Scripts. No plan for VBA to open source.
VBA is not going away - but it is not going to be enhanced other than sometimes extending the Object Model APIs.

So, while all the big Excel development dollars are going toward the web-based Office Scripts platform, the team is continuing to grow the COM-based Excel object model so that new features can still be automated via VBA.

So, Will OfficeScripts Replace VBA?

In my opinion, the short answer is No.

Instead, OfficeScripts will coexist side-by-side with VBA.  It will continue to improve.  It may even add support for new programming languages from time to time.  But it will never completely replace VBA.

And as for VBA–despite what Microsoft may secretly wish–it's not dying anytime soon.

Cover image generated at imgflip.com