The Practical Client

TypeScript Futures

Now that Google is adopting TypeScript as the development tool for Angular 2, TypeScript 1.5 is going to gain some functionality driven by features in Google AtScript. But there's more in the next version of TypeScript than just AtScript features.

When Google first introduced AtScript in 2014 as part of the initiative leading to Angular 2.0, (the Google JavaScript framework for building applications), Google described AtScript as "an extension of TypeScript." The joint announcement at the start of March that Angular 2 will be written in TypeScript is probably the logical conclusion of that original design choice. That conclusion includes some changes for TypeScript, which appear as part of TypeScript 1.5.

Why AtScript or TypeScript?
Google and Microsoft developed their supersets for JavaScript in order to support large, complex applications by providing a level of type checking and error detection not possible in native JavaScript. JavaScript developers normally avoid these problems through a combination of coding practices and conventions. However, that kind of voluntary discipline has its limits, especially as the size of a project and the number of developers involved increases.

In addition, large projects typically involve integrating multiple separate libraries developed by different groups within the project team. Communicating the APIs for those libraries between teams can certainly be handled through documentation … but code analysis tools that report on what how an API is actually implemented are preferable to documentation that can only report on what an API was supposed to be.

This is where type-safe languages such as AtScript and TypeScript come in. Sophisticated frameworks like Angular are the kind of projects that benefit from the improved error reporting that type safety provides; type-safe APIs provide better information through code analysis, facilitating communication between teams working in parallel (Gil Amran discusses these issues in a blog post about rebuilding the Wix eCommerce application -- now WixStores).

Obviously, if you're a TypeScript developer the idea that one of the major client-side frameworks is moving to TypeScript suggests new opportunities for applying (and honing) your skills. However, the announcement does not mean that developers will need to write in TypeScript to use Angular 2: Developers using Angular 2 can write all of their code in plain old JavaScript. Still, Google's adoption of TypeScript may help legitimize TypeScript as a tool for client-side development. After all, the advantages of a type-safe language that allows developers to integrate native JavaScript provides benefits for even the simplest applications.

What AtScript Brings to TypeScript
The major change to TypeScript that results from supporting AtScript functionality will be in runtime-type checking. Unlike AtScript, TypeScript essentially drops all type information from the generated JavaScript code (as Gil notes in his blog post). AtScript, on the other hand, provides more robust support for accessing type information at runtime and, as a result, checking for type safety while your code is executing.

As part of supporting Angular, the TypeScript team is adding more support for introspection (determining type information at runtime) to make type information available in the generated JavaScript code. While you may not want to check your types at runtime, support for introspection allows the compiler (or other tools) to insert type check code as part of generating your JavaScript code.

Introspection supports dependency injection management within the Angular framework: Based on type information accessible at runtime, Angular can go and find the appropriate JavaScript class needed to service the code (I have an example of this later in this column).

AtScript also brings with it annotations. Like .NET attributes, annotations are a way to include additional information about your code in your code (you can call it "metadata" if you want). Tools can use those annotations to make decisions about how your code is compiled or used. The TypeScript compiler is the most obvious tool that can leverage annotations, but the second most obvious example is Visual Studio.

The Component attribute, for example, flags to Visual Studio that a class represents an Angular component. This means that when you apply the Component attribute to a TypeScript class, IntelliSense can prompt you through supplying the members that an Angular component requires. The following example defines an Angular component that binds to an HTML element called my-app and whose componentServices member will be met by Angular providing, through dependency injection, an instance of a class called SalesOrderService:

@Component({    selector: 'my-app',    componentServices: [      SalesOrderService   ]})    

This additional level of metadata also means that Visual Studio can understand all references to a particular component and find (or rename) them reliably. This allows Visual Studio to provide the kind of refactoring support that developers take for granted in type-safe languages like C# and Visual Basic.

Also Included
In addition to the changes driven by AtScript, TypeScript is also incorporating changes that echo or support ECMAScript 6 (and looking ahead to the changes in ECMAScript 7). For example, in existing versions of TypeScript, I use code like this to establish a prefix for all the functions in a JavaScript library that I want to use in my code (in this case, the Knockback library):

import kb = Knockback

In TypeScript 1.5, I'll be able to selectively control which items I import from a TypeScript file using code like this.

import {salesOrder, customer} from 'OrderManagement'; 

In this example, OrderManagement is a TypeScript file and I'm importing references to just the salesOrder and customer functions.

There's more to come, too: The TypeScript roadmap includes more goodies down the line, the most useful of which is support for the ECMAScript async and await keywords, which will make writing asynchronous easier.

I like TypeScript very much as is. What's great about TypeScript is that it keeps getting better.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube