Original URL: https://www.theregister.com/2012/08/07/microsoft_apps_for_office/

Microsoft's Office 2013 app-maker cloud drenches developers

Visual Basic macros are dead! Long live JavaScript macros!

By Gavin Clarke

Posted in Software, 7th August 2012 10:32 GMT

It was in 1994 that Microsoft declared Office a development platform, and released the Office Developer’s Kit 1.0 for coders to turn out useful utilities.

Using Visual Basic and COM automation, programmers could control Office applications using software. Automating, say, document editing in heavyweights Word and Excel in the fragile and resource-constrained environment of Windows 3.1 was unwieldy, but in some scenarios was a great timesaver.

In 2003, the company came up with Visual Studio Tools for Office, in which COM automation was wrapped with .NET libraries, allowing Office to be controlled using C# and other .NET languages. Microsoft also came up with a variety of methods for extending Office: templates, COM add-ins, Smart Tags, Action Panes, custom ribbon tabs, and more.

Then there is Visual Basic for Applications (VBA), the macro scripting language that will not die. Lightweight and effective, VBA still exists in Office 2013, the new release currently in preview.

The problem with all these odds and sods is that they run in the client and (VBA macros aside) have complex dependencies. They do not translate well to the cloud-with-device model, in which Office may be running on a locked-down Windows RT ARM tablet or in the browser on an Apple iPad using Office Web Apps.

Hiya Napa: Is Microsoft's Office cloud IDE an island paradise?

Enter Apps for Office, yet another model for Office development, but this time using web technology. A new-style app runs in an embedded browser object, either within an Excel spreadsheet or alongside a document in a Task Pane, or alongside an email in Outlook 2013. The app is coded in HTML and JavaScript, and communicates with the current document via a JavaScript API. Many of the methods are asynchronous. These apps run either in the Office 2013 locally installed applications, or in the browser using Office Web Apps. Office Web Apps are a feature of workplace collaboration tool SharePoint, Office 365 or online storage system SkyDrive.

Programmers can get started with Apps for Office by signing up for an Office 365 developer pass. One advantage of this approach is that you can use Napa - Microsoft’s cloudy IDE for Office and SharePoint client apps. Napa is itself an app, and once installed you can create a new App for Office in a couple of clicks.

Napa is a simple affair, but it does support syntax highlighting, code completion, error highlighting, and search and replace. More importantly, it makes deployment for testing a snap. Hit the run button, and Napa packages and deploys the app to your Office 365 SharePoint and lets you launch it in the relevant Office application, such as Word or Excel, or in the browser for a pure SharePoint app.

Frustration comes baked in

There are a few annoyances in the current preview. Launch Excel 2013, for example, and it shows an “Enable editing” button thanks to Microsoft’s cautious attitude to potentially booby-trapped web-sourced documents, and then displays a sign-in prompt even though you have already signed into Office with your account.

Still, it works. Unfortunately the ease of use, in the current preview at least, soon falls apart. There is an “Open in Visual Studio” button that works nicely, once it has grabbed a ton of dependencies from the web. Once these are downloaded, the app is opened in Visual Studio 2012, the project is disconnected from cloud-based Napa, and changes are saved locally. It is also not obvious how to get an app from development in Napa through to deployment in the Office 365 app catalogue without using a full installation of Visual Studio.

Editing Excel: building a spreadsheet for Office 2013

It would make sense for Napa to link to a hosted Team Foundation Server, Microsoft’s source code control system, but there is no sign of this in the preview, which means Napa lacks features developers take for granted such as version control. Currently Napa is no more than an interesting experiment, and there are much better cloud IDEs out there from the likes of Cloud9, but with its Office 365 integration Napa has the potential to become useful.

Apps for Office themselves also show promise. The application model avoids traditional Microsoft technologies including ActiveX and even .NET: all the code is JavaScript, although you can call web services written on any platform. Possible uses include Mail apps that look up customer details and order history; Excel apps that create charts or analyse data; or apps that validate form data in Word or Excel. You can deploy apps privately or offer them publicly in the forthcoming Office Store.

There are a few limitations:

SharePoint 2013 is not required for deployment, though clients need to access an XML manifest hosted either on a SharePoint 2013 app catalogue or on a network file share, so it appears that SharePoint is a requirement for internet-accessible deployment.

Microsoft Office 2013 is beyond mature, but Apps for Office is completely new and the tools and documentation reflect that. Although it does bring Office development into the world of cloud-with-device, it feels unfinished in places, and is a difficult transition for developers used to richer technologies such as Visual Studio Tools for Office.

It is worth persevering, since the prospect of Office apps that work seamlessly locally or on the web is compelling. ®