TypeScript: a language for application-scale JavaScript development

[D_Guidi]

TypeScript is a language for application-scale JavaScript development. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. Any browser. Any host. Any OS. Open Source. From Microsoft.

[cek]

Say what you want about whether this is a good idea or not, it is clear at least part of MS is really serious about open source.

* TypeScript is under the Apache 2.0 license [1]

* Source is available via git on Codeplex [2]

* Installation is as easy as npm install -g typescript [3]

Extra bonus coolness: They've provided an online playground like jsfiddle! [4].

[1]http://typescript.codeplex.com/license

[2]http://typescript.codeplex.com/SourceControl/changeset/view/...

[3]http://www.typescriptlang.org/#Download

[4]http://www.typescriptlang.org/Playground/

[kibwen]

Also cool: in addition to the expected Visual Studio support, they've also provided support for Sublime Text, Emacs, and Vim.

http://blogs.msdn.com/b/interoperability/archive/2012/10/01/...

[DougWebb]

I started doing C# development last year, coming from mostly a Unix/Perl platform, and I'm really glad about the timing because that's when Microsoft got serious about open development. I started doing web apps using ASP.NET MVC3, and this year MVC4 was released as an open-source project[1]. It seems that a bunch of 'young turks' have reached higher management positions in most of the key software development products within Microsoft and they're all pushing for this kind of open source approach.

[1] http://aspnet.codeplex.com/

[colin_jack]

I have to admit I'm impressed with MS here.

Contrast Dart and TS. Dart announced a year ago and they're only now dealing the JS interop issue, so to most people its still only really interesting as a play thing. TS announced and from the looks of if we choose to we can immediately start using it.

I know Dart is more ambitious and maybe long term their focus on issues other than interop will be proved to be correct, but I doubt it.

[hermanhermitage]

This looks excellent a nice restrained effort. Hasn't fallen into the trap that ActionScript3 did with too much ceremony, and its nice to see a syntactic super-setting approach rather than Dart's.

Now what I'd like to see in Javascripts evolution (non backwards compatible):

    * Subract: Removing parts of the language - let crockford free to rip out the bad parts.
    * Enhance: Bring in some more taste of Scheme.
    * Replace: New scoping for var etc, without introducing new keywords.

[wingspan]

Awesome, great to see this finally released. I'm a dev in FUSE Labs (http://fuse.microsoft.com) and we've been dogfooding TypeScript for a while now. I'd be happy to answer any questions about using TypeScript vs vanilla JS, converting a large codebase, etc.

[platonichvn]

This is great to hear. I have only just started reading up on TypeScript. But I would love to know if there will be support for a decimal type. I have been following Google's work on Dart and it doesn't look like they will be implementing it last I checked. Such a feature would be a great differentiator.

[lstroud]

How does it compare to Dart & Harmony (even coffeescript)?

I know that is a long answer, but I'd love a bullet point list of how if compares to the other javascript++ languages that have been coming out over the last couple of years.

[ovidiu]

I'm wondering how to make use of an existing object system. We already have a JS framework that simulates classes and inheritance in the Java-style OOP.

[arturadib]

All of these compile-to-JS efforts are great, and as much as I love things like CoffeeScript I have to say I definitely worry about language fragmentation.

JavaScript is full of flaws, but its monopoly in the browser space has brought about one intriguing and welcome side-effect: a VERY efficient market for both employers and employees.

It's easy to overlook how important this common denominator has been for everyone involved. Employees have a tremendous amount of mobility within the industry: don't like your current JavaScript job? No problem - just about every dot-com needs a JavaScripter. Similarly, companies can today tap into a tremendous pool of JavaScript developers.

In today's fast-paced development environment, the ability to hit the ground running is key, and I worry that fragmentation will introduce unnecessary friction in the industry.

[epidemian]

It looks really good for a first release. The focus on tooling is IMO the most refreshing thing about the project; the playground is great!

I haven't dug much into it yet, but there are a couple of annoyances that i noticed in the playground that i wish will be corrected/alleviated somehow:

- The language is not expression-oriented. Once i got used to the "everything is an expression" mindset in languages like CoffeeScript or Ruby (or every functional language that i can think of) it feels quite tedious to "go back" and remember that, no, now the "if" is not an expression any more, you can't return it, or pass it to a function, or assign it to something. You can use the special syntax of the "?:" operator for an if-expression, but there is no equivalent for "switch", or "try", or "for".

- The type system doesn't seem to support parametric polymorphism. For example, the type of string[]::map is ((string, number, string[]) => any, any) => any[] instead of ((string, number, string[]) => T, any) => T[]. So the value ["hello", "world"].map((s) => s + '!') is of type any[] instead of string[], which would be preferable IMO.

[wingspan]

TypeScript will eventually support generics, as per the spec [1]:

  NOTE: TypeScript currently doesn’t support Generics, but we expect to include them in the
  final language. Since TypeScript’s static type system has no run-time manifestation, Generics
  will be based on “type erasure” and intended purely as a conduit for expressing parametric type
  relationships in interfaces, classes, and function signatures.

[1] http://go.microsoft.com/fwlink/?LinkId=267121

[scanr]

Very interesting. The Apache 2.0 Licence is comforting, makes it worth having a look. The docs are here for anyone interested in the spec:

http://typescript.codeplex.com/documentation

I like what they've done. Nothing too revolutionary, mostly adding static typing to Javascript without straying to far from the existing (or future) language or increasing the noise significantly.

Here's some highlights:

* Type inference

    function f() {
        return "Hello World!";
    }

Will do the right thing

* Explicit Typing

    function f(s: string) {
        return s;
    }

* 'Ambient Types'

To facilitate integration into existing JS libraries or the DOM, TypeScript lets you specify 'placeholders' for variables / classes that the runtime would expect to see e.g.

    declare var document;

Almost a kind of dependency injection but also a neat way to manage talking to existing code.

* Structural Typing

* Classes and Interfaces

    interface BankAccount {
        balance: number;
        deposit(credit: number): number;
    }
    
    class CheckingAccount extends BankAccount {
        constructor(balance: number) {
            super(balance);
        }
        writeCheck(debit: number) {
            this.balance -= debit;
        }
    }

* Modules

    module M {
        var s = "hello";
        export function f() {
            return s;
        }
    }

* Arrow function expressions

    (x) => { return Math.sin(x); }

[euroclydon]

Are you actually implying with the above example code that you can call a undefined "super" constructor on an interface and pass it the "balance" variable, which the interface's non-existent constructor would presumably match by name?

[bmuon]

I don't think `super` can be invoked as a function yet. I think it's only a reference to the superclass' prototype.

[oinksoft]

It seems to me that the type checking in TypeScript is extremely limited compared to what the Closure Compiler supports. The examples only show simple `fooInstance : Foo` examples, whereas Closure supports function prototype validation and such, a la C. I will need to see more elaborate examples.

Granted, there is no documentation that I could find on the website. I understand that this is a "preview," but I disagree with this way of presenting a tool. When the Closure Library was released, for instance, it was absolutely chock full of API documentation. This is because it was used for real-world projects and extensive docs mattered, even internal to Google.

There is a language specification (PDF, in the source tree) which is encouraging, but where's the manual? <http://www.floopsy.com/post/32453280184/w-t-f-m-write-the-fr.... The specification is largely a rewording of the ES5 spec with insertions where the typing additions are important. It will take a good bit for the reader to separate the wheat from the chaff, as they say.

I have more than a sneaking suspicion that this project is essentially a proof-of-concept, and that it is not heavily used at Microsoft. Do you remember "Microsoft Atlas" in 2006, at the height of the JS DOM Library Wars? In the end, they just pushed their developers to use jQuery with some code generation helpers. Microsoft's open-source track record for JavaScript is not impressive, and I think you'd be a damned fool to invest in this technology for any serious project.

[wingspan]

  I have more than a sneaking suspicion that this project is essentially a proof-of-concept, and that it is not heavily used at Microsoft.

My team has been dogfooding TypeScript for several months now, providing lots of feedback and writing > 30,000 lines of code (in many cases the new TypeScript code is shorter than the original Javascript).

[JimmaDaRustla]

It's an open-source iniative - great ideas like this are best seeded and grown through a great community effort. You sound like you want to be given the whole tree.

[rictic]

What's function prototype validation? Can you expand on this?

[spicyj]

This looks nice. I love the fact that there's no runtime that needs to be included or any overhead when the compiled JS runs.

It'd be 100% more useful if it was more aware of nullable types -- as it is, it appears that

    null * 7

compiles without any error messages. If they add a "nullable number" type distinct from "number", I'll be a lot more likely to use it.

It also appears that some other things compile that perhaps shouldn't, such as

    7[2]

and

    7["a"]

even though (7).a is equivalent and (correctly) fails to compile.

[swannodette]

They've added type annotations to all of jQuery it seems?

http://typescript.codeplex.com/SourceControl/changeset/view/...

[eddieplan9]

This is quite impressive technically, and I think the type-checking feature alone can make it appeal to those making large-scale application in collaborative development environment. I hope this inspires other similar efforts. A quick run-down of features:

- It's a superset of JavaScript. So there is no porting effort needed. (With CoffeeScript, you do not need to port if you don't want to.)

- compile-time type checking, like type erasure in Java's generics.

- module support at the language level. It's very thin. It does not give your AMD or CommonJS module, but you can easily hack around it.

- class and inheritance support at the language level. The implementation is very similar to CoffeeScript's.

[wingspan]

With reference to AMD and CommonJS modules, the spec has more info [1]:

  TypeScript implements modules that are closely aligned with those proposed for
  ECMAScript 6 and supports code generation targeting CommonJS and AMD module systems.

It also looks like you can consume CommonJS and AMD modules using familiar constructs.

[1] http://go.microsoft.com/fwlink/?LinkId=267121

[tlack]

Weird that I didn't spot a friendly list of features.. seems to have some cool ones, like a shortened function expression (from the doc PDF):

    (x) => { return Math.sin(x); }

and modules, which are implemented using the immediately invoked function expression pattern:

    module M {
      var s = "hello";
      export function f() {
        return s;
      }
    }

Syntax seems more clear than CoffeeScript and tool chain will probably shape up better. Looking forward to seeing this get some traction.

[wingspan]

Here are some off the top of my head:

1. Lambdas (as you mentioned) are not only shortened syntax, but also capture the `this` variable automatically for you. Try typing in the following at the playground in the body of the `greet` method to see what I mean (http://typescriptlang.org/playground):

  var x = a => this.greet();

2. Classes with inheritance are a big one, implemented using the IIFE pattern as well, with support for static and class members.

3. Interfaces with duck typing are very lightweight and easy to use:

  interface IGreeter { greet(); }
  class Greeter /* implements IGreeter */ {
      greet() { ... };
  }

4. Extensive type inference. In the following example, the function greet will be typed () => string:

  class Greet {
    greet(x: number) {
        var s = ' greetings';
        return x + s;
    }
  }

Static and member vars, return types, local variables, all are type inferred.

5. Javascript is TypeScript, just without typing, so converting your codebase is instance, and then you can begin adding type annotations to get more robust checking

[untog]

I like the shortened function form. I played around with CS for a while before going back to JS, but I do miss being able to do something like:

    var names = people.map((p) -> return p.name);

(or something along those lines). Funnily enough, it reminds me of C#'s LINQ:

    var names = people.Select(p => p.name);

[tlrobinson]

This looks great, but the IDE seems to be one of the key features, so we're going to need something other than Visual Studio.

EDIT: they've got syntax highlighting for some other editors, but full completion and error reporting is still needed http://blogs.msdn.com/b/interoperability/archive/2012/10/01/...

[ericcholis]

Favorite part about this, I didn't know it was Microsoft until I scrolled down!

[MicroAndMacro]

Sublime Text, Vi, Emacs: TypeScript enabled http://blogs.msdn.com/b/interoperability/archive/2012/10/01/...

[alexanderh]

What about debugging? Thats my biggest problem with coffeescript

How do they map errors thrown in the browser, to TypeScript code? If this has things like classes and such, the relationship isnt always going to be 1:1 and debugging can become a nightmare. Part of what makes javascript so great is how easy it is to debug. All these "superset" languages that compile to javascript fail hard @ debug support usually

[jrajav]

What's with the insta-downvotes whenever someone mentions Coffeescript's debugging issues? I am not an active Coffeescript developer, but I thought that debugging line-by-line was prohibitively difficult, especially in the browser. Has this changed? If not, why the animosity?

[munificent]

Source maps[1] should help with this.

[1]: http://www.html5rocks.com/en/tutorials/developertools/source...

[wingspan]

Debugging would be helped greatly if they supported source maps (http://www.html5rocks.com/en/tutorials/developertools/source...).

[malandrew]

Like someone else commented in the TC article about Typescript, this Resig quote, changing "Google" for "Microsoft" is relevant:

  "Why is [Microsoft] putting time and effort into 
  changing JavaScript when the DOM is what needs fixing?"

https://twitter.com/jeresig/status/124114331616026624

[munificent]

Ironically, improving the DOM is actually something we're trying to do with Dart: http://www.dartlang.org/articles/improving-the-dom/.

[lukeholder]

Can I write my TypeScript in coffeescript?

[streptomycin]

This seems similar to the type checking and optimization done by Google Closure Compiler?

[koops]

I've written a lot of JavaScript, including large-scale projects, and never once have thought, "Gee, I wish I had type checking."

Haven't we come to a consensus that types are more trouble than they're worth? They hurt clarity and catch few bugs.

[masklinn]

> Haven't we come to a consensus that types are more trouble than they're worth?

Pretty sure we haven't. That shitty languages with shitty type systems are mor trouble than they're worth yes, but types?

[bruceboughton]

Like spaces vs. tabs, braces vs significant whitespace, there is, and never will be, no such consensus.

[ovidiu]

No, we have not. Read John Carmack's posts on static code analysis to understand why.

[jakejake]

I have a theory about this - how you feel about static typing is related to whether you see the compiler as your friend or as your enemy.

If you see the compiler as your friend then you tend to like type checking because it blocks certain bugs and typos. It won't let you run your code until they're fixed. If you see the compiler as your enemy, as a barricade that you need to get past, then you tend to not like static types. The compiler prevents you from seeing your code running immediately.

Obviously there's other benefits to each system but I feel like this is the more "gut reaction."

[colin_jack]

Not really, i love JavaScript but do think types have their place in documenting the code and in supporting tooling (e.g. Refactoring).

[andrewla]

On a tangent, does anyone know anything about the in-browser editor they are using for the playground? It seems really slick. The javascript references something called "monaco" and the directories are all prefixed with "vs".

The code is hosted on their demo site; /Script/vs/editor/editor.main.js appears to be the main js file and has this notice:

    /*!
        © Microsoft. All rights reserved.

        This library is supported for use in Windows Store apps only.

        Build: 1.0.8514.0.win8_rtm.120711-1900
  
        Version: Microsoft.WinJS.1.0
    */

[wingspan]

I believe the monaco editor is already being used in Azure Websites and possibly the TFS preview. I wouldn't be surprised if more information about it would be released soon, they are also a major dogfooder of TypeScript.

[drcode]

Back in the day, Microsoft would use a strategy called "embrace, extend, extinguish." http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

Recently, Microsoft has been pushing Javascript very hard (embrace) and now it looks like they've started the "extend" phase.

Luckily, no one really worries about them being able to pull off the "extinguish" part anymore... they just don't have enough market power these days.

EDIT: Yes, I conceede the fact that TypeScript is OS probably addresses most of these objections.

[untog]

Except that this is fully open source, which makes it a little difficult for MS to retain control over it, no?

Re-reading late 90s M$ memes gets old after a time.

[MatthewPhillips]

You're wrong "extend" is when you add features to a standard that are not part of the standard. Since this only compiles to JavaScript and isn't being built into IE, it doesn't qualify. Dart does, though.

[jakejake]

This would still be the "embrase" phase. Extending is when they add a new feature that doesn't exist and isn't supported by the competitors. As soon as you see it compile to a flavor of JavaScript that only IE understands - then will the "extend" phase have begun.

[zokier]

TypeScript is as likely to extinguish JS as ASP is to extinguish HTML.