Among these is TypeScript, the brainchild of Anders Hejlsberg. I would not have predicted that the creator of Turbo Pascal and C# would, in 2015, be working in the open on GitHub, for Microsoft, to strengthen the Web's native programming language. But it's a delightful outcome. TypeScript is an important project that delivers useful benefits now and is moving forward nicely.
Second time's the charm
When I tried again in late 2014 I found none of those problems. But my experience was also better, I think, because I approached tasks in a more incremental way.
"Instead of having a switch that turns types on and off," says Anders Hejlsberg, "we have a dial." You can invest incremental effort for incremental reward. As you add annotations, you improve your own ability to reason about the code, and you enable tools to provide more powerful automated support for that reasoning.
There's also a multiplier effect because the TypeScript compiler works hard to infer types where it can. If you tell it that a function returns a string, it will know that a variable holding the result of that function is a string, even if you haven't annotated the variable with the string type. If you later try to assign it a number, the compiler will complain.
There's a test for that
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.
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.
Then there's the Microsoft factor. Its rocky relationship with open Web technologies over the years has left many Web developers with a sour taste that won't easily dissipate.
TypeScript is, objectively, doing everything right. The project is being developed in the open on GitHub, under an Apache 2.0 license, and it accepts community contributions. The vast majority of pull requests are from the GitHub accounts of Microsoft employees on the core team, naturally, but you can also find community-contributed bug fixes. This is not the behavior people have learned to expect from Microsoft, and it will take more than a project like TypeScript to change those expectations.
More accurate, it's an idea whose time has come back around again. TypeScript's type annotation syntax originated in ECMAScript 4 and was implemented in ActionScript 3, but never landed in the ECMAScript 5 that runs in today's browsers. Type annotations aren't part of the forthcoming ECMAScript 6, but are widely expected to land in the next incarnation of the language. Nobody knows what those annotations will be. But AtScript and Flow are betting that they'll look a lot like the TypeScript syntax, so they're aligning with it.