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.
Though in decline, Visual Basic for Applications is still with us. The latest version, 7.1, was released in 2013 and it has had a 64-bit version since 2010. But with web-based word processors becoming more popular, VBA is a technological dead end. Based on 90's era COM technology, there is no realistic way to host it inside a web app. And with JavaScript replacing BASIC as the language of the common man, creating a new "VBA for the Web" doesn't seem like a tenable idea.
.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
As we mentioned before, JavaScript is now considered to be the programming language of the common man. And Node is becoming the development platform for the amateur (and professional alike) who doesn't want or need a heavy IDE like Eclipse or Visual Studio. So it shouldn't come as a surprise that Microsoft picked those tools for building Office add-ins.
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
yo office
The yeoman generator will ask you what kind of add-in you want (ribbon command, task pane, etc.), which Office products it supports, and if you want to build it in Angular or pure HTML/JavaScript. The next command you need launches a local server for hosting your add-in.
gulp serve-static
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.