For nearly 30 years, macros have been a key selling point for Microsoft Word. First introduced in 1989, WordBASIC allowed even minimally trained typists to write computer programs that simplified their daily tasks.
During this era competition was stiff. Beside Word, there was WordStar and the then front-runner WordPerfect, each with its own macro programming language. The arms race was on, and with the business user demanding more and more features the updates were frequent.
Then in the late 90’s something interesting happened. When Microsoft created Visual Basic for Applications (VBA), a language with (limited) OOP capabilities and matching IDE, to replace WordBASIC it didn’t just create another embedded component. Originally meant to work with all MS Office products, they realized that they could license the technology. Soon many companies were offering VBA support including ArcGIS , AutoCAD , SolidWorks , CorelDraw , and even WordPerfect .
The public perception of macros saw a significant decline just after the turn of the century. So called "macro viruses" were causing havoc. Hidden inside Word documents, they were hard for virus scanners to detect.
In response, Microsoft locked down the VBA programming interface. It was still as powerful as ever, but turning off the safeties so that you could actually use it proved challenging. And most virus scanners refused to all documents that contained macros to be shared via email.
.NET and Office
In an attempt to move people away from the obsolete VBA technology, Microsoft also created Visual Studio Tools for Office (VSTO). This set of developer tools and libraries not only allowed for creating Office plugins, they also allowed stand-alone applications to manipulate Office documents.
At least that was the theory. In practice VSTO failed in both regards.
The casual programmer doesn’t want to install Visual Studio and create Office plugins from scratch. They want to record a macro, then modify it to suit their needs. The level of training needed to make the leap from "edit until it works" to starting from a blank slate is simply too overwhelming.
And then there is the versioning problem. VBA style macros are stored in plain text. This means that your code can work with any version of Office so long as you don’t use a feature that only exists in a newer version. With VSTO plugins, you are expected to target a specific version of Office. That means the developer has to be using the oldest version that anyone else in the company is on.
Speaking of which, professional developers were by and large not interested in plugins. They wanted to build servers that consumed and/or generated office documents. But VSTO is based on COM automation, meaning that it literally starts a copy of Word or Excel to do actually do all of the work. Running a separate copy of a heavy desktop application for each user of your website simply isn’t tenable.
And like VBA, you really can’t use VSTO in a browser-based web processor.
Building Office Add-Ins using Node
To get started, you’ll need to install Node. Then from admin command prompt, run these two commands:
npm install -g tsd bower gulp yo generator-office
This is for basic smoke testing, but for any real work you’ll need to run Office on the web. After opening a blank document, you can upload the manifest for your add-in and see it in action.
You may be wondering why you have to start a local server if you uploaded a manifest. Well what’s happening is that the manifest just allows your browser to load your add-in from your computer while at the same time it is running Office. In practical terms this means you can make changes to the add-in, hit refresh in the browser, and see the effects immediately. You don’t have to re-upload the add-in every time you make a change.
Since this is a web application, you can debug it using your browser’s built-in debugging tools.
To see it in action watch Build Office Add-ins with Any Code Editor and Office Online by Harrison Shapley.