A word on JavaScript and TypeScript

Office Add-ins are built using web technologies. This means that, at least for interacting with the document, you’ll be using JavaScript – lots of it.

JavaScript is a very curious language. It is obviously immensely popular: in StackOverflow’s developer survey for 2016, it is far and away the most popular language for full-stack and front-end developers, and (though by a smaller margin), is the most popular language even for back-end developers. And yet, relative to the “standard” languages like C# or Java, the language is incredibly quirky! No type safety, no out of the box classes, two types of equality comparisons (== vs. ===), and the list goes on. How do you program in such an environment?

Coming from the strong and comfortable type safety of C#, VB.NET, and Java – complete with .NET’s LINQ (Language-Integrated Query Language) and other runtime goodies – I was frustrated when first encountering JavaScript. Actually, “frustrated” doesn’t even begin to describe it. I distinctly remember biking in the rain from work one winter day. I was cold and wet, but one quizzical thought still managed to surface to my consciousness: “I wonder what’s more miserable: biking through this sort of weather, or programming in JavaScript?”

Fortunately, bit by bit, JavaScript grew on me. I actually find it quite delightful to program in it now, and appreciate the flexibility that if affords. But I still discover interesting new nuances and surprises (not always pleasant) about it every day. There is a reason for a book series called “You Don’t Know JavaScript”, aimed at the professional developer!

Still, one thing I could never get used to in JavaScript was the complete lack of type safety (and reliable type inferencing, for IntelliSense’s sake). Why couldn’t JavaScript alert me of obvious mistakes, such as using incompatible types, or misspelling a property name? And why – despite Visual Studio’s best efforts with JavaScript pseudo-execution at design time – could I not easily get the type information to flow into my functions?

Enter TypeScript, a language developed by Microsoft’s leading language experts, in an open-source, agile, “new Microsoft” fashion. TypeScript made its public debut in October 2012, and has been gaining popularity ever since. TypeScript is a typed superset of JavaScript that compiles into plain and idiomatic JavaScript. As http://www.typescriptlang.org explains:

Starts and ends with JavaScript

TypeScript starts from the same syntax and semantics that millions of JavaScript developers know today. Use existing JavaScript code, incorporate popular JavaScript libraries, and call TypeScript code from JavaScript.

TypeScript compiles to clean, simple JavaScript code which runs on any browser, in Node.js, or in any JavaScript engine that supports ECMAScript 3 (or newer).
Strong tools for large apps

Types enable JavaScript developers to use highly-productive development tools and practices like static checking and code refactoring when developing JavaScript applications.

Types are optional, and type inference allows a few type annotations to make a big difference to the static verification of your code. Types let you define interfaces between software components and gain insights into the behavior of existing JavaScript libraries.
State of the art JavaScript

TypeScript offers support for the latest and evolving JavaScript features, including those from ECMAScript 2015 and future proposals, like async functions and decorators, to help build robust components.

These features are available at development time for high-confidence app development, but are compiled into simple JavaScript that targets ECMAScript 3 (or newer) environments.

 

Personally, I love TypeScript. And in the case of Office.js, I think it is quite indispensable for writing non-trivial code. Take a look at a screenshot of some simple code snippets in Visual Studio, with all four of the pain-points I mentioned earlier. With TypeScript, each of the first three statements are highlighted as errors, and by specifying my parameter types (e.g., “table: Excel.Table”), I can keep the full power of IntelliSense even when passing objects across function boundaries.

IntelliSense across functions, by telling TypeScript what type I expect

 

For purposes of code samples in this book, I will mostly refrain from using TypeScript annotations (type names, modules, classes, and various syntax-sugar), simply so that everyone can easily get my code samples running, regardless of whether or not they’ve jumped on to the TypeScript bandwagon. That being said: especially with the async/await features of TypeScript 2.1, along with other ES6 goodness like template strings, developing with TypeScript is delightful. Once you’ve tried it, I don’t think you’ll ever look back!