This article is more than 1 year old

Microsoft: TypeScript isn't a JavaScript killer

It's not about the language, it's about the tools

Build 2012 Microsoft may have a poor track record for web standards compliance, but if the capacity crowd at Microsoft Technical Fellow Anders Hejlsberg's Build conference session on TypeScript was any indication, Redmond's JavaScript alternative has struck a nerve with coders who have grown frustrated with the web's de facto applications language.

"We have teams and customers writing, with regularity, 100,000-line JavaScript applications, in a language you could argue was designed for 100-line applications," Hejlsberg said, to appreciative nods from the audience.

During his Thursday morning talk on Microsoft's Redmond campus, Hejlsberg argued that building such large JavaScript applications successfully is simply too difficult. The bigger a project's code base grows, the more likely it is to contain subtle and confusing bugs, which can lead to data corruption, security vulnerabilities, or worse.

But Hejlsberg said TypeScript, the alternative web language he created with a team of Microsoft developers, isn't meant to replace JavaScript, but to build on it.

TypeScript isn't the first tool aimed at solving the problem of application-scale JavaScript coding. Google, in particular, has been experimenting with its own JavaScript alternatives for several years, first with the Google Web Toolkit and later with the Dart language. But Hejlsberg couldn't resist taking a jab at the Chocolate Factory's efforts for straying too far afield.

"Unlike certain other languages that target JavaScript," Hejlsberg said, "we actually start with JavaScript, meaning that any valid piece of JavaScript code is valid TypeScript. You just cut and paste the code."

Rather than simply remaking JavaScript in its own image, Hejlsberg explained, Microsoft had a different goal when it created TypeScript. Specifically, it wanted to make it possible to create world-class developer tools that would make building large web applications easier, without breaking compatibility with existing browsers and standards.

That should come as no surprise, given that Microsoft is arguably the leading commercial developer tools vendor. Even some Redmond haters grudgingly admit that Visual Studio is one of the best IDEs in the business.

But building an IDE like Visual Studio that works with JavaScript is impossible, Hejlsberg said, because of JavaScript's dynamic type system. Without the ability to know which data types a function is expecting as its parameters or what data types it's expected to return, there's no way to implement the kind of code hinting and completion to which Visual Studio users are accustomed, let alone to analyze the code for hidden bugs.

TypeScript = JavaScript++

To fix this, TypeScript starts with ordinary JavaScript syntax and adds additional features. For example, it adds a static type system that allows developers to specify which objects should be strings, which should be numbers, and so on.

This static typing in TypeScript is completely optional. Developers can add type annotation to all of their objects and variables or just a few. In fact, Hejlsberg said, specifying types for just a few identifiers in a program is often enough to allow the TypeScript parser to infer the rest automatically.

The key, he said, is that TypeScript doesn't go out of its way to create data types that weren't available in JavaScript already. "TypeScript's type system is basically just a formalization of JavaScript's type system," Hejlsberg explained. "We're not trying to make something new here; we're just trying to formalize what already exists."

Because all valid JavaScript code is also valid TypeScript code, Hejlsberg said, it's even possible to write TypeScript declaration files that specify type information for existing JavaScript libraries, granting them all the IDE-friendliness of libraries written in pure TypeScript without ever altering the code of the libraries themselves.

He added that the TypeScript community has been hard at work creating such definition files, and that the current TypeScript distribution already includes ones for many of the more popular JavaScript libraries and frameworks, including jQuery and Node.js.

In fact, Hejlsberg said, the TypeScript distribution doesn't have a standard library of its own. Although libraries can certainly be written in the language, its core resources are the same as JavaScript's.

In addition to static typing, TypeScript also introduces a new object orientation model, replacing JavaScript's prototype-based model with a model based on classes and interfaces that will be more familiar to developers accustomed to languages like C++ and Java. Additionally, TypeScript adds the concept of modules, making it easier to break large code bases into components whose code can be isolated from one another.

But even these differences aren't such a huge break from JavaScript, Hejlsberg noted, because the way they have been implemented is essentially the same as the work being done on classes and interfaces for ECMAScript 6, the open standard that is likely to become the next version of JavaScript.

"Before we declare [TypeScript] 'done,' if ECMAScript 6 moves to a different model, then we will likely follow, because we're still just a preview of what the final product will be," Hejlsberg said.

What's next for TypeScript?

But similarities between TypeScript and ECMAScript 6 don't mean they are the same language, nor will they ever be. Specifically, Hejlsberg said, there are no plans to include static typing in ECMAScript, which is the feature that really sets TypeScript apart and that enables the kind of sophisticated tooling that Microsoft envisions.

And while some of that tooling is already available in the TypeScript plugin for Visual Studio 2012, he said, Microsoft has still more planned. In particular, limited support for debugging TypeScript code is available now, but "thorough" support will come with future releases.

The TypeScript language will undergo further changes, too. One feature Hejlsberg said he would like to add to the language was generics, which he said would be inspired by C# generics but would work differently.

The mention of C# spurred another question that had been much on the minds of this year's Build conference attendees, however: If Hejlsberg, the father of C#, is spending all of his time on TypeScript these days, what does it mean for the leading language of .Net? Does C# have a future?

But Hejlsberg brushed off the idea that he was abandoning his earlier brainchild, insisting that there were enough hours in the day for him to work on both TypeScript and C#. "C# is still going strong," he said, "it's just that right now there's a big need for JavaScript to improve."

Judging by the large and animated crowd at Hejlsberg's Build session – who had to be ushered out of the room to make way for a new session before all of their questions could be answered – a great many developers agree. ®

More about


Send us news

Other stories you might like