Technology Lab / Information Technology

Microsoft TypeScript: the JavaScript we need, or a solution looking for a problem?

New language makes large app development easier, but we've seen it all before.

For all JavaScript's prominence as the lingua franca of Web development, there are an awful lot of developers who don't like it a whole lot, and as a result, a great many efforts to produce something better.

As is typical among programmers, nobody can quite agree on which bits of JavaScript are the problem. For some, JavaScript is mostly good enough, just a little awkward and ugly to write, so we have, for example, the popular CoffeeScript language. CoffeeScript makes a lot of changes to JavaScript's syntax, and uses JavaScript's object-oriented capabilities in a particular way, but doesn't fundamentally alter the way the language works.

Others think that the semantics of the language (the rules governing its behavior) are a problem too, so we have projects like Google's Dart, which offer both new syntax and behavior. And then there are the things like Google Web Toolkit (GWT) and Script#, which adopt wholesale the language and behavior of, respectively, Java and C#, merely compiling to JavaScript for actual execution.

Taking this a step even further is Emscripten which allows any language supported by the LLVM compiler toolkit to be compiled to JavaScript, and JSIL, which similarly compiles .NET programs into JavaScript.

To these existing solutions, we have a newcomer from Microsoft, called TypeScript. TypeScript is a new language that's based on JavaScript, and which compiles to JavaScript, but which, Microsoft argues, is better suited to the development of "large" applications. Pure JavaScript lacks certain language features that are taken for granted in languages such as C# and Java. For example, it has no built-in module system, meaning that there's no standard way of producing self-contained blocks of code that present well-defined interfaces to developers. Nor does it have any kind of static type checking or interfaces, meaning it's easy to, for example, rename a particular method in a class in one part of a program, but then forget to use the updated name in another part of the program.

TypeScript's development was led by Anders Hejlsberg. Hejlsberg has a long history of developing practical, mainstream programming languages; he was the man behind Turbo Pascal, Delphi, and C#. Microsoft has published an open source Node package that can be installed with npmsyntax files for Sublime Text, Emacs, and Vim; and a plugin for Visual Studio 2012. The language spec too is published and the company is inviting feedback to develop it further.

The TypeScript language borrows liberally from other languages and environments. Like Dart, it supports structural subtyping (that is, an object does not have to declare that it implements a specific interface, it merely has to support all the methods that the interface declares), and also like Dart, the static type checking is optional: you don't have to use static types if you don't want to, and if you don't, you'll just have JavaScript-style dynamic type checking. So, for example, if you declare a variable as having the type string, the TypeScript compiler will emit an error if you try to divide that variable by a number. If, however, you don't specify that the variable has type string, there will be no error at compilation time, with the problem instead occurring at runtime.

Unlike Dart, Script#, and GWT, however, TypeScript doesn't discard the syntax of JavaScript. Instead, it extends it, with the result that any JavaScript program is automatically a TypeScript program, without requiring any changes at all (albeit a program that has no static type checking or module system). Where new syntax features are required, for example to allow classes to be declared, Microsoft has sought to use the syntax currently being considered for ECMAScript 6, the next version of standard JavaScript.

Overall, TypeScript looks very conservative. There is limited type inference (function return types are inferred from the type of their return statements, for example) but no attempts to infer static types from programs with no type annotations at all (unlike the complex inference used in Mozilla's DoctorJS, say). The static type system is also simple, without anything like Dart's generics. On the one hand this makes TypeScript more familiar to existing JavaScript developers; on the other, it limits the number of problems that can actually be detected.

As with CoffeeScript, the output of the TypeScript compiler is idiomatic JavaScript. Constructs such as classes and inheritance are translated into JavaScript prototype chains in a manner that should be familiar to existing JavaScript developers, and which should also be consistent with ECMAScript 6.

For modules, there are two common patterns used by JavaScript developers, CommonJS-style modules (also used by Node), and AMD (Asynchronous Module Definition)-style; TypeScript supports both.

TypeScript was born of an internal desire within Microsoft. Groups such as the Bing team are developing complex JavaScript applications, but want to have the kind of tooling that developers of languages like C# are used to—the ability to trap errors at development time, to rename methods and variables and fix all the places that those methods and variables are used. TypeScript is Developer Division's attempt to meet those needs.

The public response to TypeScript was mixed. While some were positive about, or at least, interested in the new language, others were very dismissive, arguing that the new language added nothing of value. Still others expressed concerns that this was an attempt to "embrace and extend," suggesting that the reception might have been warmer had the language not come from Microsoft.

Skepticism about the long-term value of TypeScript is warranted, however. Developers wanting type-checked languages with good tool support have plenty of options already. Java and C# already have first-rate development environments, for example, and GWT and Script# allow those languages to compile to JavaScript so that they can be run in the browser. Indeed, GWT and Script# were developed for essentially the same reason as TypeScript, too: to enable large-scale application development. These tools also provide much stronger guarantees and much richer development capabilities than TypeScript, due to the non-optional nature of their type systems.

If GWT and Script# are a little too heavyweight, there are also tools such as JSLint, that help detect programming errors, and Traceur that provide greater language support for concepts such as classes.

GWT and Script# both require switching languages, which might be undesirable for projects with existing code, but even past attempts to add type checking to JavaScript (as Microsoft did with JScript.NET, Adobe did with ActionScript 3, and ECMA attempted with the (now abandoned) ECMAScript 4) have failed to catch on. Perhaps not by accident, TypeScript's type annotations are quite similar to those suggested for ECMAScript 4.

In spite of this abundance of options, most developers stick with plain old JavaScript. It might be that none of these previous efforts provided exactly the right mix of ease-of-use, tooling support, and ease of migration from existing JavaScript, but equally, it might be the case that JavaScript developers by and large simply aren't that interested in these features—that TypeScript (and GWT, and Script#) just isn't solving a problem that they're experiencing.

The development of TypeScript might also seem a little surprising, given that Microsoft was critical of Google's attempt to produce a new scripting language, Dart. Dart's goals aren't identical to TypeScript's—Google feels that some of the semantics of JavaScript are fundamentally problematic, and so Dart changes those semantics—but both Dart and TypeScript are designed to aid large-scale application development, using module systems and optional static type checking as the fundamental tools to support that, and both can be compiled to JavaScript.

TypeScript is, however, less ambitious, and Hejlsberg argues that the decision to build on JavaScript's semantics, rather than replace them outright, represents a fundamental difference between Dart and TypeScript, and so the criticism of Dart doesn't apply to Microsoft's efforts.

Microsoft also isn't attempting to disrupt the Web in the way that Google wants with Dart. Google envisages browsers having their own dedicated Dart virtual machine, alongside and in addition to the JavaScript engine (with compilation to JavaScript being merely a stopgap to allow Dart programs to run without the presence of a Dart VM). TypeScript, however, is meant to leverage existing JavaScript engines, with the JavaScript compatibility as a permanent feature.

With strong tooling support and easy integration into Visual Studio 2012 and Node, there's a chance that TypeScript will succeed where so many previous attempts to make JavaScript suitable for large application development. But just as likely (if not more likely) it'll simply be another name to add to the list of languages that compile to JavaScript that don't gain mainstream adoption. It'll be popular in Redmond (just as GWT is popular in Mountain View), but never quite manage to break out.

Expand full story

You must to comment.