Hello, TypeScript

Time flies. I just realized that my last entry was from May. Thanks for your feedback on my Pew Pew Manifesto! In the last few months I’ve  had a few things I wanted to write about but just not enough time. Yesterday I read an announcement by Microsoft that seems to be too important to be left out of the discussion about JavaScript cross-compilers.


Microsoft introduces TypeScript

On October 1st, 2012,  Microsoft introduced a new programming language for large-scale web application development called TypeScript:

“TypeScript is a superset of JavaScript that combines type checking and static analysis, explicit interfaces, and best practices into a single language and compiler.”

TypeScript: JavaScript Development at Application Scale

Here are a few links that you might find useful if you are interested in learning more about TypeScript:

In my opinion it is worth stepping back for a second and look at the motivation for TypeScript:
Why did Microsoft decide to invest in TypeScript?

And in extension:
Why did Google create Dart?


Why did Microsoft decide to invest in TypeScript?

It seems TypeScript wants to overcome limitations in JavaScript that prevent developers from writing large-scale web applications:

“With HTML5, the standards web platform has become significantly more compelling for delivering rich user experiences. At the same time, the reach of JavaScript has continued to expand, going beyond the browser to include native device apps (e.g. Windows Store apps for Windows 8), applications in the cloud (e.g., node.js running on Windows Azure), and more. With these developments, we’re starting to see applications of unprecedented size written with JavaScript, despite the fact that creating large-scale JavaScript applications is hard. TypeScript makes it easier.”

“JavaScript was originally designed to be a client-side scripting language for web pages, and for many years it was limited to event handlers that scripted a Document Object Model (DOM). As a result, JavaScript is missing many of the features necessary to be able to productively write and maintain large-scale applications, namely those that create distinct contracts between components and developers.”

TypeScript: JavaScript Development at Application Scale

That echoes pretty much what Google says about their motivations for Dart.


Why did Google create Dart?

In Dart – A Modern Web Language (Google IO 2012) Lars Bak and Kasper Lund describe the thought process that eventually lead to developing Dart. At around 8:30 Kasper Lund explains some of the biggest shortcomings of JavaScript in a section called Fundamental JavaScript Issues. The most important issue is in my opinion JavaScript’s keep-on-truckin’ paradigm, where mistakes are tolerated to a degree where almost anything goes and wrong types lead to unusable results (~11:00). That segment is really worth watching. I highly recommend it.


“Don’t blame JavaScript, it’s the developer’s fault!”

The second session I would like to quote is Google I/O 101: Introduction to Dart. At around 11:00 Seth Ladd uses this JavaScript example for illustrating that in Google’s Dart you can reason about unfamiliar code more easily:

function recalculate(origin, offset, estimate) {

Seth explains:

For example the JavaScript example at the top reads, the calculate method takes an origin, an offset, an estimate, and I don’t even know what it returns.

What is an origin?
What is an offset?
What does this return?

Given this function signature, you know almost nothing.

Of course, you can pray the developer left comments that annotate all the types of the parameters and return value. If you are lucky, they did. But then your tools don’t know how to parse written text. Worse case, you’re reading the function body, and if you’re reading the function body, you’ve broken encapsulation, and you’re in a bad spot. You really want to know what the method is, what you can pass to it, and what it can return.

What Seth describes has happened to me many, many times when working with foreign JavaScript and Lua code (which is another dynamic language that should be avoided in my opinion). I often hear arguments that reiterate the mantra of “don’t blame JavaScript, it’s the developer’s fault”. For example, incoherent JavaScript code is caused by developers who don’t understand how to write code in JavaScript. Or, ambiguous function signatures are the result of undocumented code, which developers failed to provide. Or, developers should read a good book about software design before writing any code. Or, if you use the JavaScript library xyz then you can avoid all of those development problems.

If those arguments from JavaScript enthusiasts were really true, why did Microsoft invest in TypeScript and why did Google create GWT and later Dart?


The problems are real

In my opinion those arguments from JavaScript enthusiasts all ignore structural problems of JavaScript that are very real. To illustrate my point: If a language allows typos and keeps on truckin’ with unusable results – would that be the developer’s fault? Frankly, yes, but developers are humans and make mistakes. That’s why we need languages and compilers that catch errors like typos as early as possible, that is, at compile time. Pointing out that a developer just has to know the language and should simply not introduce any typos doesn’t help anybody.

Nobody is perfect. That’s why we need good tools and languages. TypeScript, Dart, and GWT seem to provide just the right tools for helping you creating large-scale web applications.