Friday, May 8, 2015

Exploring TypeScript and what makes it sweet

I've been watching the TypeScript project for a little over a year now, since the 1.0 release. The concept really interested me, but as is the case with many new language conventions, I wasn't sure whether or not it would catch on. However, the recent announcement that Typescript would be used to build AngularJS 2.0 gave me confidence that TypeScript was legit and here to stay. I decided it was time to start a little sample project (posted below) and explore.

While building said project and preparing to write this post, I came across quite a few "Introduction to TypeScript" articles. This is not intended to be one of those articles. They have their place, to be sure, and I used a number of them to get started on my journey. However, I want to take a different angle - I want to pose back to you, and answer, the same questions that were in my head when I started watching the TypeScript project:

  • Why should you use TypeScript in your next web or mobile project?
  • What makes TypeScript sweet - meaning how will it make your job easier and your project better?
  • Essentially, how does it put the sugar in your java[script]? (sorry, I had to)

Here's what I liked about TypeScript:

TypeScript creates better JavaScript than I do.

I'm not ashamed to admit it. I didn't have to do much with JavaScript early on in my career during the Web 1.0 days, and eventually started working with it through jQuery. TypeScript similarly helps to bridge that gap; you still need to know how to write and work with JavaScript, but the "compiler" handles the heavy lifting, especially when it comes to converting classes into nested functions and methods into prototypes. At some point, I'd like to learn how to do that myself; for now though, I'm happy to have the help. I can write objects and classes as I would in other languages I'm more familiar with, and still get pristine JavaScript.

On that point, I'd also argue that TypeScript code is cleaner and more maintainable than raw JavaScript. Download my .ts file below, compile it, and take a look at the two files side-by-side. Which one would you rather maintain? The JavaScript version is very clean, but still - TypeScript for me, please.

TypeScript is excellent at helping you organize your code.

I think the best way to describe the state of the JavaScript code in just about every large-scale web application I've inherited or consulted on is "hodge-podge". Some of it's in the page files. Some of it's in .js files. There's duplicate code all over the place. In general, it's because the code was poorly organized, and is thus a pain to work with.

TypeScript offers the ability to create modules that really help in this area:

  • Modules work like namespaces in C#. They help to group like objects together, as well as avoid name collisions with other objects and over-saturation of the global namespace.
  • The export keyword restricts access to code outside the module, clearly defining what's intended for public consumption and what isn't. Law of Demeter, anyone?
  • Classes within a module can be split across multiple files for simplified maintenance, readability and reuse (more on that in a moment).
You may notice that I didn't split my code into separate files. I decided not to simply because I wanted to post a single Gist file for all of it. If it as part of a bigger project, I'd probably have a separate file for each class.

TypeScript helps you share & reuse your code.

This is the result of points #1 & #2. At the risk of stating the obvious, if you have high quality code that's well organized, it's easy to share or reuse it in multiple projects. For example, if you were to split up my code below so that each class was in a separate .ts file, it would be easy to maintain the classes as part of a common library, but also to select only the pieces you want for a specific application. Maybe you don't need to make API calls, but you need a Timer or a ResultLog? The structure and conventions of TypeScript make this easy.

When I mentioned to a colleague that I was working on this article, one of his first questions to me was, "So how does it work with something like Angular"? To ask it another way, how do you share and reuse your existing JavaScript code with new TypeScript code? The answer - a d.ts file, or library declaration file. This allows TypeScript to understand and interact with an existing JavaScript library through interfaces. In the case of Angular, you can download the library declaration from the Definitely Typed Git repository or NuGet; d.ts files for most of the major JS libs are available here as well. For your own JavaScript libraries, you'll need to create your own declaration, or rewrite the library using TypeScript directly (as they're going to do with Angular).

* * * * *

TypeScript certainly offers other benefits as well, but these really struck home with me. I really liked working with it, and definitely intend to incorporate it in future projects. In fact, I'd go so far as to say that I don't think I'd want to attempt building a JavaScript-heavy project without using TypeScript for at least a portion of it. As JavaScript is now commonplace in all kinds of different software projects, you must be able to write high-quality, reusable JavaScript, and TypeScript will definitely help you do that.


Here's my sample project - it's an API testing module modeled after a PowerShell script I wrote a few months back. The TypeScript module code is below; there's also a sample HTML page that shows how to execute it:

Wednesday, May 6, 2015

Recap - Building Windows Apps with JavaScript is even easier

I had the privilege of representing SPR Consulting at Microsoft Ignite yesterday. It was my first experience attending a really big industry conference, which was cool in and of itself. Along with that came the opportunity to catch a session by Michael Palermo IV titled "Building Windows Apps with JavaScript is even easier". I thought it was a good high-level overview of some new app development features that are coming down the pipe with Windows 10, and wanted to share my notes on a few of Michael's topics that were of particular interest to me:

Hosted Web Apps

As Michael explained it, this is a web application that runs within the context of an app. Have an existing web site you want to have a corresponding app for? Just start a new Universal Windows app project, edit the config file to reference your site, and Build the Project.

Boom, it's an app.

This demo really impressed me. Not only does this mean you can create an app from an existing web application without many changes, but any changes you make on the web are instantly available within the mobile app without the need to redeploy. As Michael mentioned though, this is really only going to work well for web applications that utilize responsive design.

Lastly, and almost as cool, you will also be able to access Windows APIs from this app. This means the website you just turned into an app can also access device features like Notifications, Camera, Calendar - even Cortana!


Manifold.js

"Create hosted apps across platforms and devices". Basically, you point this tool at an existing website, and it will read the meta-data of the site and generate a Hosted Web App for you! You can run the utility either through the Manifest.js site, or locally after installing the corresponding node.js module. Besides Windows, this tool can also generate Hosted Web Apps for iOS and Android (using Apache Cordova).

Essentially, it's going to become much easier to take an existing web application and package it up as a Universal Windows Store app. I've recently been dabbling with building Windows apps using JavaScript in pursuit of an MCP certification, so anything Apps + JS is of particular interest for me right now. I'm looking forward to trying out these tools & techniques in the coming months once Windows 10 is released.

NOTE: Building Universal Windows apps requires Windows 10 configured for development + Visual Studio 2015.