Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

TypeScript: Industrial-strength JavaScript

Jon Udell | Jan. 20, 2015
The TypeScript language is most succinctly described as an optionally typed superset of JavaScript. Since existing JavaScript is valid TypeScript, you can begin using the TypeScript compiler — and TypeScript-aware tools — by simply changing filename extensions from .js to .ts.

There's a test for that

The growing popularity of dynamically typed languages like JavaScript happened to coincide with a growing appreciation for the practice of writing self-testing software. As a result, there's been some tendency to conflate the two trends. If your test coverage is sufficiently robust, some say, there's no reason to incur the overhead of static types.

We can debate the feasibility of writing tests that obviate the need for static typing. But if you buy the argument that type safety becomes important at large scale, TypeScript invites you to consider how you want to invest your testing effort.

Tests are, after all, another kind of overhead: more code to write and maintain. Arguably what can be tested mechanically should be. If computers can figure out whether two software objects are compatible, humans ought to delegate that job to them. Writing tests, like writing the software those tests exercise, is a creative act that should require and benefit from human intelligence. Automatic type checking is, from this point of view, a way to free up human creativity for higher purposes. 

One of those higher purposes is effective naming. "There are only two hard things in computer science," it's famously said, "cache invalidation and naming things." The names of variables, functions, classes, and modules are the most fundamental kind of documentation.

It's hard enough to coin names that usefully describe their roles in a program. It's even harder to adjust those names as those roles evolve during the ongoing development of a program. That's partly because naming anything well — in software or in any other domain — is intrinsically hard. But in software there are special risks when names that appear in different contexts, and mean different things, can't easily be recognized as such. That's the situation in JavaScript. There are a number of incompatible workarounds for organizing code into modules, but the language itself doesn't support any of them.

ECMAScript 6 takes a major step forward. It provides a standard way to organize programs, which may spread across many files, as sets of modules. That mechanism, which TypeScript adopts, is a boon for large-scale development. When module dependencies are declared in a standard way, programmers can more readily understand those dependencies, tools can automate that understanding, and code refactoring becomes less risky.

For example, in a conventional JavaScript environment it's risky to rename a module-scoped or class-scoped variable, function, or class that's referenced in many places, perhaps from many files, because there's no way to know if the name is intended to mean something else in another context. A TypeScript-aware IDE knows and can make such refactoring a safe operation.

 

Previous Page  1  2  3  4  Next Page 

Sign up for MIS Asia eNewsletters.